'FeralA' decoder -- free-to-use

[John Dyson]

2 hours ago, jabbr said:

John prefers less HF content than I do i.e. "darker' so YMMV.  I find that too many layers or too high tone numbers seem to remove the "sparkle" which can be part of a recording so try --tone=-60 or -70 for example, or fewer layers

 

I think that you are seeing my problem when doing demos -- I have poor judgement for EQ, and it also seems like everyone has differing tastes.   So, I give up on trying to attain perfection for my decoding efforts, but instead try to show the general improvement.   Then, others (you'all) can do the professional quallity decoding job!!!   I cannot produce a 'finished' professional result, but have made a decoder that can do the job, with the right people using it....

 

The decoder is complete -- all of my massive decoding/EQ Christmas efforts are intended to find missing capabilities.   The tool is 'usable', I am also working on learning -- so the use can be much better documented....

 

John

 

[mocenigo]

On 9/28/2020 at 2:17 PM, John Dyson said:

Right now, the decoder is VERY VERY deficient in documentation.   I am spending much of my time this week producing some useful documentation, esp for beginning users.  Most likely, on Fri late afternoon, there should be improved documentation, with an updated/complete exhaustive man page (converted to pdf for reading), and a better beginners guide.   Also, I hope to have a more general 'user guide for success' type thing.   Using the decoder now is actually reasonably easy for people who are comfortable while using Linux/Windows command lines, and a simplified version new set of options might fit into the limiting scope of a GUI.   The spectre of a GUI appears to be more and more practical for both DA and FA decoding.

 

Also, on Friday (or Saturday), there will be a minor quality improvement release, targeted to improving one of the auxiliary features.  There are no more features to be added or substantively changed.   The expected change is a slight retuning of the anti-sibilance.   Even though the current version works pretty well, it is a little too likely for the anti-sibilance to add a 'hitch' to a vocal.   I have made the slight change to better avoid creating the 'hitch'.   (The change is not really 'tuning' per se, but is slightly changing the behavior of the dynamic notches.)   Associated with the changes, there is a performance improvement in the anti-sibilance code, so that more fine control can be provided without penalizing the speed.    This improvement already exists and is part of my ongoing decoding testing.

 

John

 

 

This is great. I hope you will open source the CLI version soon.

[John Dyson]

On 12/9/2020 at 5:50 PM, mocenigo said:

 

This is great. I hope you will open source the CLI version soon.

Thanks for the comments -- I take them very seriously.

 

About the docs -- they ARE TOO deficient, but I am working on a remedy from BOTH directions.   One direction is to further simplify the use, and the other is to complete the docs with all of the previous and new, nifty features.

 

The decoder has gone through a major evolution while, instead, I should have been finishing the Christmas presents.  First, I am going to give an excuse (but very honestly true), my hearing easily accomodates frequency response errors.   I haven't accomodated the FA sound, but frequency response errors go away very quickly in my perception.

 

Here is the bottom line -- I tried to get some realism and was getting WAY WAY too much criticism about the midrange response.  Everything got re-evaluated, and some things that had been 'fixed/unchangeable' for 3yrs.    All of the changes and realizations forced me to rewrite the low level EQ code, because I had a design botch.   The filter frequencies were essentially correct (mostly), but the filters were being translated from the 's' domain to the 'z' domain with wierd errors.   I corrected that problem.   (basically, my 2nd order conversion routine botches 1st order results -- therefore all of the FA EQ was a bit twisted.)

 

Here is why the vast technical improvements have simplified the documentation problem:

All normal decoding is like this:   --tone=xx.xx  --fcs="<nlayers>,auto,<famode>"   [ --fw=<classical,mix> ]  [--wof=<0.8409,1.19> ]

(square brackets are optional, as needed)

<famode> is one of two choices

<nlayers> is 4, 6, 8, 10.

<tone> is -44.5, -46, -49, -50, -52, -54.5, -56, -60

(Bold is most common, Italics are seldom used.)

 

Note the above -- NO POST DECODING EQ!!!  For pure decoding, normally no --pix (for HF) or --pi (for LF) is needed.

 

Sometimes an input compensation of --b18k22k, or --b18kxxk or --b15kxxk might be needed to help with HF rolloff on source material.

Sometimes minor bass compensation at 1.25kHz or 1kHz might be helpful, but that is SOMETIMES.  I am still testing.

A proportion of the material might need some adjustment, but so far, my classical examples, all test classical test examples, my high res purchases, many of my CD purchases have all passed the test.   I need to test more.  (This includes the Telarc recordings that I still have.)

 

All of the previous capabilities need to be documented, because they can help with 'poor mans mastering', but look like they are mostly not normally needed for decoding.

 

I am hoping to get done with this by Tuesday.  Since the changes are so vast, and I just got this basically finished a few hours ago,  there is a HUGE, MONSTEROUS amount of testing needed.

 

Thank goodness that the builtin, basic DolbyA compatible decoder is deadly accurate -- otherwise this would be impossible.

 

So, I guess Tuesday it will be ready.   It is now ALMOST easy to use.

John

 

PS:  about the source release -- I can (and will, upon request) give out the basics of the DolbyA emulation right now -- but is written in SIMD C++, and not easily ported to Java, C or any other language like that.  (a language without SIMD would expand the source immensely and slow down the code by a factor of 6 to 8.)   However, the basic algorithms for the multi-layer attack/release calculations are the answer to accurately emulating DolbyA -- and anyone can have a copy of that within days (I need to edit out a few high-tech dependencies.)   The source recently changed so rapidly that tracking the changes would be impossible.    For the DA decoding, I will divulge anything right now except for the anti-MD algorithm (because it is not yet proven, but works very well -- I need a PhD student to help me with the math -- wierd Hilbert stuff), and also the anti-IMD part of the code (keeps the last bit of ripple out of the gain control) is something that I want to document some day before releasing source.

 

The source only depends on POSIX, and all libraries that aren't POSIX or part of the OS type stuff are re-distributable.

 

I will release it (but there are still two major embarrassing sections:  the input band splitting filters and the I/O code.)   I have a solution for the band splitting ugliness that will require a month or two because of time scheduling (probably 2 days of work.)   Also, the I/O code just needs an overhaul, but the .wav file metdata code is mixed in along with the time synchronization.    The I/O code is a real complex mess, but I'll probably release what exists now.

 

Don't expect the decoder source to be anything less the complexity of a graduate research project -- I have worked on many major programs, including being one of the last maintainers of the SVR4 Unix, wrote a lot of the FreeBSD kernel, managed projects with satellite communcations, etc...   The DHNRDS decoder is the single most frustratingly complex piece of software that I have done by myself.

 

To understand how to work with the code, having strong C++ expertise is needed, or the code would just be strange to try to understand.  Also, there is a threading message passing scheme -- so each 'time consuming' section of code can easily be split into a thread.

 

For a source release -- it will be MONTHS, not YEARs.    The only limitation is my own ability to physically do the needed work.

 

John

 

 

 

 

[John Dyson]

As many of the users know -- I have been beat-up about the lower midrange on the decoder.  My hatred for the woody/horn-like FA sound made me over shoot on some processing.

 

There are many improvements in this version, including better lower midrange.  Even the lower midrange is increased, it still doesn't sound like the cr*ppy recordings normally available -- it sounds like the output of a mixing board.   Previously, it sounded liek approx -1.5 -> 2dB cut in the lower midrange, but now that is fixed.

 

About the release:  I missed a minor bug, so I must delay until Thursday night.

 

The quality is BEAUTIFUL.   I made some demos, but unfortunately they are not 'trimmed' to a snippet length yet.   I'll trim the examples tomorrow (time for bed) and make them publically available.   The full decodes are available for the reviewers, and are intended for a preview, NOT a serious review of the decoder.  I am very sure that the bugs are now fixed.   (You won't believe the clarity of Karen Carpenter's vocals, clarity of Linda Ronstadt -- or how good 'Mrs Robinson' from Simon and Garfunkel can sound.)  ABBA (my windmil tilting) even sounds a LOT better.

 

One of my problems in my own demos is that it appears that I sometimes used too many decoding layers.   The effect of using too many layers is that the midrange is suppressed...   That is probably a big part of the problem.

 

I am attaching a prelim version of the Usage doc -- it might get updated again before the release, but only clarifications.   I have been very distracted lately so my language skills have suffered worse than normal.   At least, the Usage doc will describe the decoding method.

 

Most importantly -- the POST-DECODING EQ is totally gone (well, there are vestiges built-in to the --fcs command itself.)   Some recordings do EQ slightly differently, but I have simplified the usage to the point that the user doesn't have to worry about 'frequencies' or things like that.

 

This doc will closely reflect the release on Thursday.   There will be more complete info available after things settle down (days, not weeks), and will be derived from earlier, more complete documentation in the deep past.

 

John

 

 

 

Usage-V1.7.0E.pdf

[John Dyson]

6 hours ago, John Dyson said:

As many of the users know -- I have been beat-up about the lower midrange on the decoder.  My hatred for the woody/horn-like FA sound made me over shoot on some processing.

 

There are many improvements in this version, including better lower midrange.  Even the lower midrange is increased, it still doesn't sound like the cr*ppy recordings normally available -- it sounds like the output of a mixing board.   Previously, it sounded liek approx -1.5 -> 2dB cut in the lower midrange, but now that is fixed.

 

About the release:  I missed a minor bug, so I must delay until Thursday night.

 

The quality is BEAUTIFUL.   I made some demos, but unfortunately they are not 'trimmed' to a snippet length yet.   I'll trim the examples tomorrow (time for bed) and make them publically available.   The full decodes are available for the reviewers, and are intended for a preview, NOT a serious review of the decoder.  I am very sure that the bugs are now fixed.   (You won't believe the clarity of Karen Carpenter's vocals, clarity of Linda Ronstadt -- or how good 'Mrs Robinson' from Simon and Garfunkel can sound.)  ABBA (my windmil tilting) even sounds a LOT better.

 

One of my problems in my own demos is that it appears that I sometimes used too many decoding layers.   The effect of using too many layers is that the midrange is suppressed...   That is probably a big part of the problem.

 

I am attaching a prelim version of the Usage doc -- it might get updated again before the release, but only clarifications.   I have been very distracted lately so my language skills have suffered worse than normal.   At least, the Usage doc will describe the decoding method.

 

Most importantly -- the POST-DECODING EQ is totally gone (well, there are vestiges built-in to the --fcs command itself.)   Some recordings do EQ slightly differently, but I have simplified the usage to the point that the user doesn't have to worry about 'frequencies' or things like that.

 

This doc will closely reflect the release on Thursday.   There will be more complete info available after things settle down (days, not weeks), and will be derived from earlier, more complete documentation in the deep past.

 

John

 

 

 

Usage-V1.7.0E.pdf 95.07 kB · 2 downloads

 

Here are the promised snippets.   Some of the material (e.g. American in Paris) gets a lot better later on, after the snippet time limit.   Also, the ABBA recording is high detail, and has a smooth frequency balance, but is atypical of the ABBA sound.   Mrs Robinson and the Fleetwood Mac examples just might be pretty surprising.   The Carpenters result is about as good as I have ever heard ANYWHERE.

 

* The decoder *really is* on schedule for Thursday.   The only reason why I am not sending it afternoon today is that there is ONE minor LF problem that needs correction, and I have no time today.   This note is being squeezed in before I need to leave to take my Mom to the hospital.

 

One thing that might 'twist' ones hearing -- there is a lot of midrange in these recordings, but they don't have the nasty peak (horny/woody sound) in the lower midrange like most consumer recordings have.   NOTHING that the DHNRDS produces will sound like the junk being sold to consumers since the middle 1980s (the reason why I walked away from my HiFi hobby in approx 1990.)

 

https://www.dropbox.com/sh/mjmdfxu8gdweoc2/AACE7AQA1kZ0AIFNxar_sZoJa?dl=0

 

NONE of the examples is cherry picked, and each one took about 30seconds to find the settings.   The Carpenters example needed a small amount of massaging -- and I mistakenly left the anti-sibilance enabled on a few other recordings, but it wasn' tneeded (I really DID only take under 1 minute to find the settings, and took a few minutes to do each run.)   I ran these recordings in high quality mode, even though the --normal mode is better than the previous release.

 

John

 

 

[John Dyson]

One major correction to some of the examples -- I cannot hear frequency response errors very well.  At least some of the recordings needed a 9kHz -> 21kHz shelf.    I am listening for distortion, and REALLY CANNOT hear frequency balance problems.

 

I'll create another version of the examples.   They should sound even MORE distortion free.

 

John

[John Dyson]

17 minutes ago, John Dyson said:

One major correction to some of the examples -- I cannot hear frequency response errors very well.  At least some of the recordings needed a 9kHz -> 21kHz shelf.    I am listening for distortion, and REALLY CANNOT hear frequency balance problems.

The decoder sounds the way that it does based on design -- I just forgot a step.  The correction is a single character in the command line.

 

I'll create another version of the examples.   They should sound even MORE distortion free.

 

John

 

[John Dyson]

The new V1.7.0F version is now available.   It resides in the usual place -- pointer is below.

 

For new users, refer to the gettingstarted and Using documents.   I have attached copies here.

 

Basically -- to decode a .wav file, you basically do this, but with some variations:

 

da-avx --info=1 --input=in.wav --output=out.wav --tone=-50 --fcs="6,auto,fGg"

 

The --tone= value can be -50, -54.5, -56, -51, -60, -66.  (choose a number that looks like this.)

This calibration (--tone) value is important, but is dependent on the recording.   It is not a death sentence if the tone value is approx correct, but you want to iteratively try for the best value.

 

If you have the full package avaliable, you can replace --output=out.wav with --play, and it should play the results real-time.   The entire package is in the Linux and Windows distributions.

 

The correct value for --fcs is also discussed in the Using document, but the docs won't tell you everything -- for ANYONE, including me -- using the decoder is a bit of a skill.  It is NOT difficult to use, and the settings are relatively simple, but with names/meanings that have evolved.  Typical values for 'fGg' also include 'fg^^^', 'fGg^^', 'fgb' and a few others.

 

I'll produce some GOOD examples tomorrow -- sorry about the previous examples.  I am TERRIBLE at making demos, but the good news is that feedback from the demos forced me to correct some STUPID bugs.

 

https://www.dropbox.com/sh/1srzzih0qoi1k4l/AAAMNIQ47AzBe1TubxJutJADa?dl=0

 

If the problem runs at all for you, and you are having troubles -- ask questions here or in private.   I'll do what I can to help you get started.  The program is very complex,  can be slow, and will suck your computer dry of cycles.   It does LOTS of very sophisticated processing to recover a recording.   This program is NOT simple like an expander or an FFT noise reducer -- be patient.  If people have problems, and they are of the fixable type, then a new release with bugfixes will come poste haste.

 

John

 

 

gettingstarted-V1.7.0F.pdf Usage-V1.7.0F.pdf

[John Dyson]

Minor usage update -- I have found that on some recordings the super highs are too strong.   I suggest adding the 'S' mode modifier when you find that happening.

 

Some recordings are deficient above 18kHz, and the 'S' mode modifier disables the compensation.

 

There is a post decoding EQ, where there is a 9kHz -7.35dB HF shelf.   At the end of the curve, there is a slight 2.39dB shelf at 18kHz.  That gives an upward kink at 17-18kHz, but this might be too much on some recordings.

 

John

 

[John Dyson]

Mea Culpa -- Currently working in a new computer setup.   The wrong files got sent to the build machine and compiled, and a cursory check showed that the program worked.   However, the wrong versions got built.   The version is close (as I was checking early this morning), but needs a change.   Nothing major, no changes to settings.   There will be an improvement tonight.   That slippery, slimey sound got through.

 

BTW -- dont' expect the reassuring strong midrange that consumer recordings have.

 

John

[John Dyson]

Found the problem  -- still double checking everything.   Somehow two numbers got swapped.

I knew that the distribution version was working, and 'made sound', but after checking this morning (using the release version rather than my test version) there was a difference somewhere.

 

Gonna double check the release version this time.  (They should be the same, but sometimes (often) I make mistakes.)

It is possible that 4 layers might have sounded okay, but I doubt it.

I'll do the release/test better before it gets late tonight.

 

John

 

[John Dyson]

The decoder error is fixed and updated.   Also ran some tests, including on Windows.   (Windows is terrible, Microsoft broke in and required all kinds of stupid things, interrupting the build.)   The sound is IDENTICAL between Linux and Windows -- Linux is where I build and do majority of tests.

 

I have attached the C++ bugfix (sorry for the stutters in the code, as I was trying to figure out which was which in the parameters.)   You might notice that the difference in the switched parameters are very minor, but are very important.   Because they were constants, and one of them cannot be easily calculated as a C++ constant (the 9dB one), i just used a high precision literal constant for the values.  (probably should also comment them.)

 

Also, I removed some of the super-high frequency compensation so that the 'S' submode won't be needed as often.

 

The Usage document was updated to suggest using the fGg mode instead of fg (requires different arguments) if the sound has weak dynamics.   The 'fg' will sound smeary if you use that when 'fGg' is needed.   On the other hand, sibilance can get out of control if you use 'fGg' when 'fg' should have been used.   Each of the EQ has a 'different' sound.   One of the modes will always be correct.

 

During testing, I hadn't tried ABBA Gold and More ABBA Gold for a very long time.   Even though the ABBA sound seems compressed, those recordings are one of the few POP recordings that make the MF band do much gain control.   The ABBA Gold sounds really good with '--tone=-44.5' ( a very high, but correct value), and decoding mode of 'fGg+'.   (remember that I suggest trying 'fGg' first -- it appears to be correct most often.   Sometimes a modifier is needed.)   Of course, 'fg' mode can also be correct, but in slightly fewer cases.  The intense sound of the Gold recordings is corrected by the very high calibration value (--tone=-44.5).

 

The new decoder is V1.7.0H and has been tested.   (The darned switch of the constants was very unfortunate.)   It caused some weird effects.   Those numbers are REALLY critical.   Here it is:  (no AVX512 version -- it will be slower until at least the 11th generation of Intel CPUs.)

 

https://www.dropbox.com/sh/1srzzih0qoi1k4l/AAAMNIQ47AzBe1TubxJutJADa?dl=0

 

This was really frustrating...   I'll have some demos tonight -- finding the problem was much higher priority (severe drift between different number of layers -- should only have 3dB difference in level, not response balancel), and correcting the actual cause.   Each two additional layers above 4 will lose 3dB of level.  (yet another verification of correctness!!!)

 

Sorry about the bug.  Have fun -- again, the demos will be ready about +9 or +10Hrs -- with the correct decoder, and using standard knobs.   The frequency response balance WILL be correct.

 

John

 

ADD-ON -- forgot the attachment with the bugfix.   Added now.

 

 

fdiff.txt

[John Dyson]

I found some recordings that need EQ.

Some pop recordings need an additional EQ command:  --pvh=12k,-6 or --pvh=9k,-7.35

This EQ is essentially the same as the built-in 9k.   both end up at 21k (for 9kHz) or  24k (for 12kHz) for their EQ stop.

 

IMPORTANT:  when you have to do huge amounts of EQ, like this 12k or 9k one.  It is important in the

decoder for the EQ to stop at 21kHz or 24kHz.

 

3kHz differences in filters/EQ at high frequencies are important.   They are magic that minimizes or cancels

certain kinds of distortion.   When used on output

 

I found this need for EQ issue when doing some decodes for the demo.

I'll add a submode for this in the next release.

 

John

[John Dyson]

My hearing is failing me.   The demos will not be coming tonight.  I have some other people who are also interested, but I have to be a little more disciplined with them -- because they don't know my foibles or the complications in the program.

I promised them at approx +26Hrs from now, same for the FA people here.

 

Also, there'll be a new release to be able to handle the new EQ add-on.   The EQ appears to be VERY important, but my hearing just adapts immediately, and is very frustrationg.

 

Everything in the decoder is following a set of rules that I have derived, but the problem is based on lack of specs (kind of like a few missing constants, and I don't know what they are.)   This is like everything is all matched up, doesn't produce distortion because of crazy interactions, but what is the last step?

 

There IS a lot more progress being made, and the results tomorrow will have correct HF EQ.

John

 

[John Dyson]

DE-BORKED SOME MAJOR THINGS IN THE DECODER:

 

Only one decoding mode.   All others are not needed.

A lot more super highs.   Since there is no spec, and I cannot hear above 14k, and the response curves between bands on DolbyA for 9kHz is only a Q of 0.420, I didn't know that there was a loss of about 10dB at 20kHz.   This problem is also fixed.   Basically, they aren't using HF1 for FA encoding -- HF1 is easy to disable for decoding.  Right now, all that needs to be done is '--hf1off'.

 

I realized a line-up problem in the layers, a 3dB error per sequence. (This changes a few things, but now the calibration only has a range of about 2dB in normal cases.)   No more -60dB, then -44dB -- NOTHING AT ALL LIKE THAT.   More like -44.5dB vs -43dB, sometimes -46dB or sometimes -42.67dB (magic number.)  The line-up problem caused a spread, then a dependency on content.   The calibration IS still important.

 

I know that people are tired of this -- that is okay, we are running some A/B tests starting tomorrow, and will make them available.  DO NOT expect the same thing as before.

 

John

 

[jabbr]

When I run H it says 1.7.0A on the output line.

 

Are you saying that --hf1off should be specified? Or is another release pending?

 

Also docs are confusing :   fGg or fgG ?

[John Dyson]

6 hours ago, jabbr said:

When I run H it says 1.7.0A on the output line.

 

Are you saying that --hf1off should be specified? Or is another release pending?

 

Also docs are confusing :   fGg or fgG ?

Tee hee hee :-).

PLEASE DO NOT WASTE YOUR TIME WITH THE CURRENTLY AVAILABLE RELEASE.   Also FORGET ABOUT ALL OF THE DECODING SOPHISTICATION -- it is all gone.   Call this 'automatic' decoding!!!

 

Answer:   In the upcoming new release, the ONLY command is now 'fGg' or 'fgG', which are the same thing.

The new version:   this will sound crazy, but it is TRUE:   all decodes use the base 'fGg' command, sometimes with some LF modifiers, or slight HF boost for lossage from media.   All decodes (99%) use exactly the same --tone=, or within about +-0.06 on the calibration

 

Please listen to these -- I'll have the decoder ready tomorrow.   I put together some demos for a very very picky technical group of people, so I got REALLY serious (I have always been serious, but I felt that this is my last chance.)

 

LOOK AT THE METADATA ON THE DECODED FILES -- NOTE THE SIMILARITY?

https://www.dropbox.com/sh/v90m7q56g64tfgo/AACao_I34J7x2ZJu91qpKG4wa?dl=0

 

John

 

 

 

[John Dyson]

For those who haven't seen the decoder in action, I am providing a video of what it does.

The information is 'dense', but when you look at the video:

 

The layer is specified on the left hand side.   The gains are in each of 4 colums -- the first is LF, then MF, then HF0, then HF1.    The most active are HF0/HF1.    Each gain for each layer has a MID/SIDE component.  (On DolbyA it is Left/Right.)

 

The number to the far right, for each layer, is the output level.

 

When you look at the gains, there are three numbers:  lowest, average, highest.   On the HF1 band, you might see something like: -14.50, -14.50, -14.50 for when there is no audio.   When there is audio, you might see something like: -14.50, -6.00, 0.02.   This means that the gain actually sweeped between -14.50 and 0dB, probably between one and ten times (yes, it could be 10 times!!!)

 

When you look at each gain on each band (LF through HF1), the effective gain is all added up.  So, when you see that there is 8 layers, and the gain can be sweeping all the way from -14.50 to 0 on 3-4 of the layers, that is one hell of a lot of gain control to do without distortion!!!

 

The audio output is DECODED.

 

Here is the movie: (you'll have to download it first.)

https://www.dropbox.com/s/xy5oz7c1tywuacg/example4-2020-12-20_01.04.02.mkv?dl=0

 

John

 

[John Dyson]

I've recovered the code from my last minute mistakes.   The location (the same) of the snippets  is the first link below...
The decoder REALLY works, and is almost as easy as doing a DolbyA compatible decode now.  (The DolbyA mode is currently  licensed, but the FA mode is free touse.)   I'll supply consumers a license file for DolbyA upon request (it will always be free for consumers.  Even more free when I open up the source code -- only delay is that it needs internal clean-up.)

1)  The bass is now correct.   (really frustrated  that I made the mistake)
2)  I ran the decoder at a higher-than-usual quality mode:  '--fz=opt', which is a good tradeoff between improved qualiity (mitigation of modulation sidebands from the decoder, and some mitigation of any previous DA encode/decode cycles that was done during production.   --fz=max takes more time as --fz=opt is approx realtime, --fz=max is approx 2X slower.   There are almost 'forensic' modes that are incredibly time consuming, but push the sidebands (distortion) down to almost audible insignificance.
3)  For those who cannot or not all that interesed in the decoder, I produced a movie from the screen of the decoder running.    The message is in a previous posting.
4)  I'll be doing the *corrected* decoder release on the site where I regularly work (HERE, at AS) with the testers/those who participate.  

John

[John Dyson]

The simplest ever-to-use decoder.   Only one FA initiator now.   Only slight post decoding EQ in conjunction with minor change for typical classical recordings.

Version: V1.7.2C

 

Refer to the usage document.   Refer also to the previous snippets.

 

It is now usable for ANYONE who can use command line.  There is almost no 'tweaking' except for the case of certain classical or estoteric recordings.

 

https://www.dropbox.com/sh/1srzzih0qoi1k4l/AAAMNIQ47AzBe1TubxJutJADa?dl=0

 

John

 

[John Dyson]

New -- broken build correction release:  V1.7.2D

 

One of the decoder software users caught a  bug in the code.   The correct version wasn't moved to the upload machine nor the Windows machine.)  The correct version is now uploaded.

 

Same place:

https://www.dropbox.com/sh/1srzzih0qoi1k4l/AAAMNIQ47AzBe1TubxJutJADa?dl=0

[John Dyson]

Several important usage suggestions:

 

1)  Try to use at least the --fx quality (--fz is preferable.)   With the new lineup, the layers are working directly against the DolbyA encoding signals, and producing a lot of 'fog'.   The --fx and --fz switches are good at removing the fog by changing from a gain*signal type calculation to a very complex way of calculating a new signal.

 

2)  Don't be suprised if some decodes are a bit grainy -- the grain happens when the calibration is wrong.   So far, I have seen calibration levels of:  -42.68 (about 98% of my recordings), -50 (about 3-4 of my recording packages, including Beatles remasters), -60 (The Lamb recording from Genesis).   Look for the lower -50 level on classical recordings, it happens quite often.

 

The fact that the calibration is almost always the same further shows that the decoder is becoming more correct.

Second guessing a black box design is incredibly difficult.

 

Also -- I updated the examples to those without bad modulation distortion.   (MD sounds like a FOG over the recordings.)

 

John

 

[John Dyson]

Several major fixes -- it has most foibles removed... know that most people haven't had a chance to try the latest version, but they will be amazed.

 

Listen to HOW BAD the originals (RAW) vs decoded versions...   There might be the need for some HF rolloff on some songs, but this is truly accurate WRT they SHOULD sound like:

https://www.dropbox.com/sh/v90m7q56g64tfgo/AACao_I34J7x2ZJu91qpKG4wa?dl=0

 

The problem has been getting exactly the correct HF/MF and LF balance.   Any error can make the sound wrong, or the sound drift from using 1,2,3,4,6,8 or 10 layers.   In fact, NOW THERE IS LITTLE DIFFERENCE BETWEEN # of layers, which is a major achievement.   You can use 1 layer or 10 layers, they sound the same. I admit that there might still be a MINOR static balance issue, but no-one can tell without a reference -- and NO-ONE has valid references, other than perhaps recording engineers under NDA.

 

Thanks to those who have helped me get the right sound.

Also, the CORRECT calibrations are all based on -42.68 dB, which matches the usual -12.85dB in DolbyA pretty well.  (30dB higher than -42.68.)   Take 5 is definitely -45.68, for example -- not -50.

 

All I can say, listen ot the demos -- they really  don't sound any difference no matter the number of layers.  (except for hiss.)   The HF/MF/LF balance is the same.   I chose 8, but noticed some gating on certain songs -- probably only recorded as 6.   Again, makes no difference.

 

I will be soon stripping out all unneeded FA code, and there will be a new FA switch (only arguments are minor modifiers.)   There is no need for vast variabiity.

 

The needed EQ was VERY VERY VERY un-intuitive.

The current decoder is the final version with this command set.

A LOT of test code is going to be ripped out!!! YAY!!!  (I'd like to see about 1k to 2k lines removed.)

 

John

[John Dyson]

Just found something interesting, which demonstrates something that I heard a long time ago:   They used DolbyA to compress/brighten Karen Carpenter's vocals.   It appears to have started on the 1975 Album Horizon (might be on the 1973 Album, but it certainly wasn't as egregious.)   The new decoder is very accurate, and renders transparent things that are otherwise unclear or just suspect.

 

Also, instead of a calibration of -42.68 on the 1975+ albums, they appear to have given approx 4.5dB greater headroom and used -47.265dB.    I detected bad gating at -42.68, so started chasing every -1.5dB.   When at about -47dB, the -1.5dB was close, but not quite right.   It took some tweaking (a very small increment) to get rid of the ragged edge in Karen's vocals.

 

Once the recording was smoothed out, I could hear that DolbyA compressed sound in her sibilance.  (it is a kind of squashed, smeary sibilance) -- big tell for DolbyA.  A rolloff at 6kHz or 9kHz doesn't help.

 

John

 

[John Dyson]

New decoder version coming today/tomorrow.   This is the result of helpful feedback and also has the ability to do a deeper decode.   I'll also post final demos (with the additional layer removed) at the same time as the new release.

 

I just found the availability of more detail in the recordings, luckily, the decoder already had the capability to extract it.   It was an experimental feature, and has been for several months.   The common --fcs="8,auto,fGg" type switch simply needs a usage modification to access the feature:  --fcs="+9,auto,fGg", where an extra layer is added at a strategic spot.

 

The current examples DO NOT undo that deeper layer, but the new upcoming demos will access that deeper layer.  I just realized that the detail is existant in the recordings -- I heard the suspicious 'tells' in my decoded examples, even forgetting about the '+' command.   The demos concurrent with the release WILL have the full decodes (of course, snippets because snippets are necessary.)

 

Demos: (sans the extra layer removal.)

 

https://www.dropbox.com/sh/v90m7q56g64tfgo/AACao_I34J7x2ZJu91qpKG4wa?dl=0