'FeralA' decoder -- free-to-use

[John Dyson]

Follow-up about the 100-200Hz that seemed to be missing.   It was really odd, because no matter what I did through normal means, it couldn't be added back to the signal.

 

There were mistakenly two places in the code where there was a 150Hz equalizer...  One was in it's normal place where the 150Hz on down equalizers are placed in the code.  The other 150Hz EQ was mistakenly installed where the 250Hz to 1kHz+ LF EQs are placed.   For some reason, there was a 150Hz EQ in the 250Hz+ section.  The sections are right next to each other, so should have seen it, but the ugly -3dB 150Hz  wasin the wrong place.   When making the upper LF 'thin', it will tend to maintain a proportionality on down in frequency, so this kind of thing can be more difficult to discern than one might think.

 

When removing the extra -3dB 150Hz, actually only changes at -1.5dB at 150Hz, and then modifed the EQ further down to make it better.  This is why it was primarily an upper bass/lower midrange problem.

 

There might be a  few other minor changes, but the upper bass is back!!!   This had been frustrating, because there only needs to be 1 EQ at each frequency step, and the 150Hz was already in its correct place...  (One 150Hz was +3dB, the other was -3dB, cancelling each other out.)

 

It appears that this had been a factor creating frustration for almost the previous day.

After the low bass is corrected, then the release should be on its way.

It seemed like it might take a day or so additional (maybe longer) to fix the problem, but now it is under control.  The program is written with a  lot of discipline,  thereare very few times where this kind of mistake has been made, so didn't look for it.

 

 

 

[John Dyson]

Announcing RELEASE3-V5.7.2Y, seemingly with 'THE SOUND'.

MOST IMPORTANT, whether or not this really is 'THE SOUND', I have to thank all of those who have helped over the years.  There is special thanks for those who have held on to hope for so long!!!!!   Anytime a tester/reviewer privately allows me, I'll allow myself to mention their IDs online in the forum, with thanks.

 

The public demos and decoder are in the same locations:

 

Demos: https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

Decoder: https://www.dropbox.com/sh/5xtemxz5a4j6r38/AADlJJezI9EzZPNgvTNtcR8ra?dl=0

 

It seems that we finally got 'the sound'.

There might still need to be some minor mods, but are easy to do 'following the rules' within limited constraints.  The new 'rules' are now very narrow.  The generally correct sound is fragile, and it is easy to lose it.

 

The last set of changes were extremely minor, mostly needed because of overly restrictive self imposed  'rules' in the 'LF'.   Previously, in order to minimize the number of variables, almost all EQ had been limited to certain frequencies and +-3dB, +-6dB.   There were numerous other constraints that changed over time, but needed to keep sane.   Until today, the restrictions for the LF had been +-3dB per EQ, but found that the final LF EQ needed to be +-1.5dB, +-3dB and +-4.5dB, but no changes to the frequencies in the valid list.

 

* The LF has been very frustrating because it always seemed like it was 'close to correct', but any change overshot the goal.  By making minor changes to the 'rules', the goals could be zeroed-in.   This is, of course, within the current framework.  Previous frameworks, before about 6months ago were hopeless.  That previous hopelessness came from a misunderstanding about the needed architecture.   Just had to change the 'rules' back then!!!!

 

It is fully expected that the HF might need a few minor mods per user feedback (sometimes, it still sounds a little 'metallic' to me.)   The bass might also need minor reshaping, but there are very, very tight constraints.   The correct bass was found because there ended up being an extremely strong 'tell' where the signal lines up and the highs 'pop'.   Previously, the LF 'tell' was so wobbly as to almost be useless, but with the new +-1.5dB steps, the 'tell' that was previously weak, became extremely strong.

 

ADD-ON:  The slightly metallic highs will be addressed in a few hours.   There are a few possibilities, the simplest being EQ.  However there are also some things that might actually be helpful in addition to EQ.  Basically, there is yet another anti-distortion step that hadn't been added.  It *could* be that some fog is modulating the signal, and a slightly stronger anti-fog is needed.   Believe me -- I have some really powerful techniques to recover recordings, yet they do NOT require 'gouging' out noise per-se.   These are very very subtle techniques without snake-oil hocus-pocus  -- it might be best to be somewhat conservative at this stage.  It might not have been best to enable any of the semi-pass anti-distortion, but it has really helped with the detail.

 

The most wonderfully fortunate thing was enabling most of the anti-distortion (anti-fog) mechanisms.   It is sometimes hard to tell that it is enabled until doing direct A/B comparisons, but it REALLY helps to remove previous gain control modulation distortions.   You WILL likely hear details that you never heard before, and these are REAL, ACTUAL details in the recording that were previously obscured.

 

 

[John Dyson]

Started getting good feedback this V5.7.2Y.   There *will* be a 'Z' in a day or so.  It will remove the 'metallic' or 'brittle' sound, and I am listening to the fix right now.

ADD-ON: plus even more clean audible detail...

 

I am not totally sure if the problem was EQ at all, but the 3rd level of anti-distortion totally removes it.   Of course, I'll re-disable the 3rd level to verify the EQ matter.   Then, when the 3rd level is re-enabled, the result should be perfecto.

 

Really sorry about letting the release out with the 'brittle' sound, but I only caught it in review while the uploads were occuring.   The 3rd level of anti-distortion has been ready in the wings, and it was just a matter of transcribing/translating the code from an earlier version.  (The new architecture is lightyears better than earlier versions.)

 

There is a*slight* chance of 'Z' being ready 1st thing in morning (my time), about 9-12Hrs, but the decodes do take a while, and more testing is needed.   The only change will be the 'brittle' thing, frightened to make any other changes at this point.

 

 

[John Dyson]

Release V5.7.2Z is ready.

All I can suggest is those who might not believe it -- the results have met the goals, now we need a speedup.

A quick listen might be in order 🙂.  A few good people really have had faith, and it was worthwhile.

 

The previous V5.7.2Y got some comments that I didn't expect, so did 'X'.   I had mistakenly thought that they were good enough, but I was wrong.   So, I listened carefully to the kind comments and criticisms, and also added/restored most of the system developed through the years.   The 'Y' release was pretty good, and did get some very positive comments, but noticed some issues when listening carefully for certain 'distortions'.   The transition from 'Y' to 'Z' was a change in technology from 'Model T' with one layer of turbo charged anti-distortion to a 2022 model luxury hybrid with all of the bells and whistles.   The frustrating thing is that the maximum speed is still only 40mph, and needs some speedups.  The technology & sound quality is there, just some algorithmic speed optimization is needed.   All of the comfort of the luxury vehicle is in place.

 

The detail accessible to ones hearing can be astounding.  It is plausibiy as good as before FA encoding, and probably as good as the input to the final tape right after mixing.  I knew that the architecture could do it, all of the recent problems have been about EQ.   It is so nice that some have REALLY *helped* with truly constructive and honest criticism.   Importantly along with the constructive criticism has been some testing/review and encouragement.

 

Demos: https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

Decoder: https://www.dropbox.com/sh/5xtemxz5a4j6r38/AADlJJezI9EzZPNgvTNtcR8ra?dl=0

 

Got some feedback from a few with positive exclamation points on 'Y', but the V5.7.2Z is even better.  'Z' is probably much better.

Basically, all but one anti-distortion capability is now enabled.  I ran some frequency response tests, and the response is exactly as expected, and the anti-distortion has an effect of approx 0.01-0.05dB change.   The downsides of the anti-distortion schemes are nil.   Adding any more hat-tricks would be risky right now, and the quality has hit a point that we would be far into diminishing returns.

 

Improvements in this version over Y are:

1) Better EQ for the HF.  The big problem was more temporal than freq response.   You'll notice vocals less buried.  Correction of the brittle sound also.

2) Enabling another anti-distortion layer.

3) Add back in truncated super-LF.

 

If there is any 'ear burning' in this release is that the bass is passed through -- sometimes the material DOES have bass.  (Not that boom boost, I mean BASS.)

 

The audible improvements over Y:

1) No metallic HF.   Nice, rounded sound, no audible distortion.

2) Mitigation of lingering upper LF/lower MF intermod.

3) Minor corrections in LF temporal behavior.

4) Add back in the lowest LF.  Might not be desirable for those with systems that go 'all the way down', because masters sometimes have noticeable low bass (I mean 30Hz bass.)

5) Extreme detail.  When a recording has a vocal with a silent background, the vocal detail can be heard down into the background (no audible modulation distortion.)

 

There is a strange audible behavior that is sometimes weird to get accomodated to.   There is no warm 'modulation distortion' in the decoded output.  Most recordings ARE warm, but the warmth that people become accustomed to is mostly modulation distortion.   The sound without modulation distortion is 'different' and has a very 'clean' sound, but not excessive warmth  or enhanced highs.

 

THERE IS NO ENHANCEMENT IN THE DECODER, it simply recovers the signal...  Sometimes sound like an enhancement.

Also, there is one h*ll of a lot of noise reduction when possible.   It is challenging for a DAW noise reduction scheme can do as much as the FA decoder can without negative artifacts, but with the caveat that the decoder cannot remove noise from before a step or so of DolbyA NR prior to FA encoding.   So, if a source actually  has hiss, it cannot be removed.  However, if the hiss was added in a later stage, it can disappear.

 

 

 

[John Dyson]

Gonna try to do some public legal-sized Supertramp snippets...  Frustratingly, their songs don't usually accomodate 'snippets' as well as some other material, but I'll try.  Getting some really interesting (good sounding) results.

 

I now know why Supertramp has been so much trouble since the early days of manual EQ -- Supertramp EQ is slightly different, and is different between albums.   Apparently, to give that brighter, psuedo-higher quality sound, there is a bit of HF pre-emphasis in their recordings.   The result is that decoding Supertramp recordings becomes insufferably bright, and difficult to listen to.  Since I am much better at EQ than even a few months ago, it is pretty clear that they are freely using Q values of 0.7071 (good, normal Q), but also 1.414 (makes a hump in the response) and 2.0 (makes a bigger hump in the response.)   For some of the songs to sound correct, that 'hump' is needed to compensate for the 'reverse' hump when encoding.

 

Anyway, if I can some up with some Supertramp snippets, I'll do so.  ABBA snippets are also probably coming, but those are produced automatically when finalizing the normal, full recordings.  Supertramp is a very different' animal'.

 

 

[John Dyson]

I just got a personal message from a local AS reviewer and source of encouragement...   Some of my responses to his comments would be helpful for others also.   I have tried to remove any personal aspects to this message response, and if I let anything private leak, then I apologize:  (this is typical of a response to helpful critical commentary)...

 

Original critical comments:

 

still a slight metallic sound

perhaps more bass might be better

 

Response to review commentary:

 

If I add almost any more bass, then it fogs up the recording...  I don't know why, but the current decodes are not done in the very highest quality mode (just very high quality.)  I'll see if the fogginess will go away with more bass in the higher modes.   The current bass sequence 'follows the rules', but more bass can be chosen and still 'follows the rules'.

 

Another artifact of the FA decoding with anti-distortion enabled is that some of the 'warmth' is erased...  A portion of that warmth (not all of it) comes from the modulation distortion.  The modulation distortion gives a satisfying warmth, but isn't really on the original mix.  In the 1960s, when DolbyA appeared, some engineers with *really good* hearing could even detect the modulation distortion when passing through only ONE DolbyA unit.   Internally, we are using 9 of them, and originally 9 were used to produce the recordings.   That is a lot of gain changing energy being added to the signal, therefore producing AM signal (as in AM radio), which is part of the 'warmth' of FA recordings.   I am fighting the problem of 'how much warmth comes from FA, how much warmth comes from bass'?     If you are concerned about very low bass, some additional very low (30Hz) bass can be added without causing this diffiicult choice, but at the higher bass (100Hz) -- this is where the troublesome decision starts.   I am ALWAYS thinking about this.  (Again, this 'warmth removal' in the FA decoder is a complex algorithm that trims off the AM sidebands -- is it trimming off too much?   Can it trim off too much?  I don't know.)

 

Also, the metallic thing -- it JUST MIGHT be that there is still too much HF.  This might be a technical reason about the internal sample rate, or possibly the output EQ sequence might still be a little incorrect.

 

Another 1wk max will be allocated for quality matters, and the original comments about the sound are being considered carefully..

 

Summary:

 

The original critical comments are being considered *very carefully*, and I agree with them 100%.   The only caveat is that there are tradeoffs, and I'll try to work around any negative consequences of changes.   My own perceived 'negative consequences' might actually be improvements.   This is why it will take a few days to think and listen!!!

 

THANKS!!!

 

 

[John Dyson]

Just did another review, with my hearing working -- and considering the comments above -- the HF is still a dB or so too hot.   There is a step-down that can correct this problem.

There are several HF steps, easy to do -- the A/B comparisons are still tricky because must wait until hearing is very best to work with HF.

 

ADD-ON:

Hey -- I kept wondering where it came from (the excess HF?)   When I tried to turn it down, it got worse...

THERE WAS A HORRIBLE BUG....   It is being fixed, hopefully tonight.  Actually had +EQ when it should have been -EQ.   I am getting too old...

 

I think that if the HF is set lower, the sense of midrange and bass will improve.

Also, in the EQ pattern, I should have kept a LF EQ.   Adding in that LF EQ will improve the bass.  At the time, it sounded like I should remove it, but I was wrong.  The code is being reverted to a canonically correct EQ sequence for LF.

 

Things are settling out so that there will be a V5.7.3A, probably tonight or in the mornging.  Even though this release is BUGGED!!!, it will get better -- much better.  It has probably gotten worse, and worked as well as it did out of luck.

 

It is SOOOO nice to have people with very good hearing and patience to help direct the choices.  It is sometimes like working blind.

 

ADD-ON:  the step-back didn't take very long...   It *does* sound a lot better.  Thanks to the reviewer!!!

 

 

[John Dyson]

There *will* be a release through the night (USA Eastern time.)

 

There was one SW bug:   a lambda function was defined incorrectly, causing an EQ sequence to work improperly.  That lambda function is corrected, so there should be several dB less at 20kHz.   This will revert the code to what I had intended.  (It was tested with a different way of expressing the EQ, but the conversion to the lambda function was faulty.)

 

* The lambda function(s) were added to select between newly added anti-distortion mechanisms or not.  Since the selection is more than a line with an if statement, a full function would be best, and it is repeated some number of times for each frequency.   I wanted to keep the frequency/EQ lists as a table, but also prefer inline code for this kind of thing, so when converting from 'normal' code sequence to a more complex lambda function, I screwed up when writing the function for one of the EQ styles in the sequence.   Basically, the EQ >20kHz was changed from the appropriate -6dB rolloff to a +6dB boost.    Sadly, after making the change, I couldn't hear the defect.  The upcoming V5.7.3A is running the demos right now.

 

There is one implementation improvement:   added bass back in.  There was an EQ sequence where I had removed a required bass boost because it seemed to 'sound better'.  Of course, my taste sucks, so that is also reverted to the original intended EQ sequence.

 

This one will have HF closer to what was intended (just didn't do enough testing on the final version), and the bass will be added back in -- mistakenly removed because of my bad taste 😐

 

[John Dyson]

The release was expected to be done by now, but there was yet another improvement, then an addition to correct a side effect of one of the fixes...

 

1) Fixed the excess highs.   This problem came from the addition of a 'lambda' function (which is like an inline function) meant to implement the anti-distortion mechanism.  One of the options in the lambda function was to implement the 'maximum filter' specification for a given frequency.  The frequencies that need maximum filter are at 21kHz on up, whose filter skirts reach to upper audio frequencies.   Basically, the maximum filter was mistakenly written as maximum boost.  My hearing couldn't hear the error...   The lambda function was corrected.

 

2) Added bass back in.   That lesser bass was a mistaken choice.

 

3) Fixed the 'smush' in sibilance.   This was an error in my choice of pre-emphasis and de-emphasis.  Smush is gone, but the lack of 'smush' tended to increase the brightness of the HF.  This 'smush' effectively did HF compression.

 

4) So, what I had to do is to figure out the correct approach to rebalance the HF and LF, which is likekly to change the same mechanism as item (1) above.

 

The good news is that the fix was not to 'tweak' anything, but to change two of the EQs in the calls to the 'lambda' function, which will naturally soften the highs.   The change is basically to change one of three modes in the call to the lambda function.   No biggie, but will cause another 4-5Hrs delay.  (Decoding 60 demos at realtime takes a while.)  Isn't it amazing that changing two numbers (from 0 or 1 to 2) takes so long?

 

 

 

 

 

 

 

[John Dyson]

I thought that V5.7.3A would be good, and it almost is good.   Too much FA compression is left in the result.  It IS better than FA, but why decode the material when there is still a big part of the compression is left in?   I won't bother people with the V5.7.3A decodes -- they are obviously not good enough from a dynamics standpoint,  which I CAN discern.   Most likely, the EQ IS tolerable, but no sense in people doing a review when the expander is leaving too much of the original FA compression in the decoded material.  (The FA decoder can ONLY expand, and the decoding result is good existence proof that FA material is pretty strongly compressed.)

 

The FA decoder sibilance has always been a problem -- either burning one's ears, hitch, or smush.   Approx the correct combination is now found, but there is still too much compression left over from FA.   There is a solution by changing a small part of the pre/de-emph, but that takes time to test/verify, etc.   Then after finding a good prospective version, there are the demo decodes, so a fully tested answer still takes 3-4 more hours.

 

Sibilance and the general pre/de-emphasis is probably the 2nd most tricky part of the decoder, mostly because the immediate audible effects of a pre/de emphasis  change are small, except the general expansion amount of HF.  However, various peripheral aspects of the sound can be greatly changed.   In the most important case, the general sense of expansion, the base amount, is set by the pre/de-emphasis also.  (The pre/de emphasis are totally complementary, but have an effect on the shape of the expansion curve.)

 

Here are the previous sibilance defects:  Shrill, smush, 'moves around', has a 'hitch', and probably others.   This pre/de-emphasis yet another Tetris  game, but now is pretty well understood -- just tedious.  Must listen to more-than-several recordings for 'hitches' (e.g. SOS on ABBA, Superstar on Carpenters), 'Shrill' (Brasil'66 vocals), 'moves around' (many, Carly Simon, Carpenters, etc), 'smush' (Anne Murray).  Of course, all artists produce recordings that trigger any number of sibilance defects, and these are NOT problems with the recordings.   It is all about finding the correct list of approx 12 EQ gains at specific frequencies.        (Most likely, the actual HW design is a single 3rd order filter or two 2nd order filters that have a complex composite curve, but that is too hard to listen/adjust.)

 

Working away -- I REALLY do not want to waste anyone's time with a really silly, minor defect.   We are SOOOOOO close, and compared to anything in the past, nearly perfect.  Also, the way that even the X or Y decoder workedPROVES its viability (Z sucked.)    It always seems like the perfect result is close, but it seems to like to play whack a mole.   I think that we are now finished with the rabbit hole phase :-).

 

When it is ready in a day or so, I'll make it available.  I respect your time too much to waste it.

 

 

 

[John Dyson]

Because the results have been erratic due to haste and frustratingly variable hearing, the work on the project has necessarily become more methodical.   The design/architecture of the decoder is very easily capable of being   *perfect*.   Unfortunately, one of the major persistehnt flaws about too much super-HF (brittle, metallica sound).   This lack of quality comes from my inability to quickly choose between a list of approx 9 output EQ settings (three choices each.)   There is the fear of BOTH too little HF (sounding very dull) or too much HF (metallic sound.)

 

Given these challenges, and my hearing only being reliable for about 15minutes every 4Hrs, the testing/review has really slowed down.  These last few days, I am actually working MORE on the project than before, and reviewing EVERY LITTLE item at this point.   EVERYTHING and EVERY EQ is being reviewed/tested/and cleaned up if needed.

 

The most important effort is to control that overly bright or metallic sound.   There HAS been progress and much better details, better dynamics -- but also must be done very methodically.   ALL of the anti-distortion mechanisms have been enabled for the next release, and the ONLY difference in sound caused by the anti-distoration being enabled is more detail...

 

Once in a while I might upload a *unannounced* release, usually with comments uploaded at the distribution site.   I have promised *myself* that the next *announced* release on AS and my private meails will NOT have the excess HF/metallic sound, but I guess that it might need to be a few more days to be sure.

 

TRYING VERY HARD, apparently with poor 65yr old hearing.   The hearing is NOT an excuse, and I must learn to more completely overcome the problems caused by my hearing.

 

My guess is that the next *announced* release will be coming in 2-3days, at least.  Maybe 4-5days.

Other than the excess HF, there is a not-directly-associated problem of ugly sibilance.   I have a solution for the sibilance, but doing a lot of testing, and understanding the interactions between correcting the sibilance and other aspects of the decoder output.  There is a LOT of work being done, and careful comparisons with previously more acceptable releases, non-FA materials from the past, and even the raw FA cr*p being sold to frustrated audiophiles  today.   No stone is being left unturned.

 

There is NO due date, but will be coming soon. (like the 4-5day timeframe.)

 

 

 

[John Dyson]

The release is about 1day away.   Working on one last flaw -- thin bass.   This has been a major set of improvements, but has required a lot of changes, a lot of evaluating every previous step.

 

The current test demo is missing bass, and is too bright.   This all comes from the rework that produces more detail, but as an oversight, there was a loss of bass.   The correction is simple, and low risk.   Sometimes, because of the interations, things like the output EQ need to be revisited from scratch.  When doing so, there is a risk, sometimes requiring an iteration or two.

 

 

[John Dyson]

Three releases are planned for sometime today or soon thereafter:

 

* V5.8.1F, the latest, measurably flat between 20Hz and 1.5kHz, midrange between 1.5kHz->3kHz matching the 20Hz to 1.5kHz response, and the total 20Hz to 20kHz freq response matching the LF response.   The HF response between 3kHz and 20+kHz is still a problem to accurately measure.   The LF response is in the order of +-0.3dB, but is probably better than that because of the kind of errors in the measurement technique.  This is the first time in the current lineage that there has been great care for avoiding extreme HF.

 

* V5.8.0A, a version liked by a reviewer, and admittedly has some positive attributes to the character of the sound.   This one is about +-1dB in the LF range.

 

* V5.8.0A0, the same as V5.8.0A, but with the improvements reflected in V5.8.1F.  (Less garble, better HF intensity control.)  The general sound will be very similar to V5.8.0A, but a little more clean sounding.

 

There are some improvements in V5.8.1F that produce a profoundly better, smoother sound (e.g. Supertramp Dreamer and ABBA 'Livingstone' from the Waterloo albums) are more clean and less jumbled.   I'll try to give the 'jumble' improvement to V5.8.0A and produce a V5.8.0A0.

 

What are the differences?   V5.8.1F has a clean sound, very similar to a normally miced recording, not warm but also not 'stark' sounding.   V5.8.0A has a notably warm sound, similar in character to FA, but not as extreme.

 

The V5.8.1F wouldn't be done at this time other than the flatness, and the garble in at least several recordings is now resolved.   The solution to the garble problem was well within normal techniques, but was also novel in some ways.  (A staged use of EQ Q values, all with common sense advantages, also matching the Q graduations from LF EQ to HF EQ, simply adding an in-between stage to the sequence.)

 

The goal of 'tonight' might or might not be achieved, but this sequence of  code versions has been continually tested with improvements well into diminishing returns.  The only profound 'break' has been with the 20-20kHz EQ sequence (producing the V5.8.1F flatness.)   The there are also some minor improvements in V5.8.1F which should be very simple to back-port to V5.8.0A series.   I am feeling a LOT of pressure for a speedup in the very high quality modes, and the technique has been waiting in the wings for a few weeks.   The new math supporting the anti-fog/distortion mechanism is 'uncommon' in a similar way as the band splitting uses 'uncommon' methods.

 

Demos for V5.8.1F will be appearing in a few hours, V5.8.0A should already exist in my archives, might already be on the site.   Also, a V5.8.0A0 set of demos should be coming soon.

 

Which one is the 'best listening?'   I dont' know, but there are some listenability advantages to the V5.8.0A series.   For my own purposes, I'll be using the V5.8.1F (or later) version, which can be 'remastered' into any desireable form.   One might think of V5.8.0A having a type of 'mastering' already applied.   If V5.8.0A continues to be preferred by some, I'll plan to add the speedups to that code lineage also, with absolutely no EQ changes -- just much quicker decoding at the highest quality modes.

 

 

 

 

[John Dyson]

Doing a more careful review between V5.8.0A style sound and V5.8.1F style sound, it appears (to me) that we do not want 'flat' response.  This means that V5.8.1F, being truly 'flat' relative to the FA recording needs one more additional layer of LF EQ to be accurate.

 

Most likely, when it is ready, V5.8.0A0 will be the most listenable version for now.

 

There will have to be a V5.8.1G instead of V5.8.1F to give the most accurate sound from an FA recording.

Several months ago, I came up with a proposed method of EQ that would convert a raw FA decode into a proper recording, but truly didn't think that we needed it anymore.

 

So, for now:  V5.8.0A and V5.8.0A0 will be the most listenable versions.

There will be a V5.8.0G that adds the EQ correction from flat starting with V5.8.0F, with a simple, apparently already known EQ to create V5.8.0G.

 

There is also another reviewer who had some comments about the resulting sound character...   From V5.8.0G, I'll be trying to understand the exact kind of failing in the decoder, looking at some of the proprosed solutions.

 

Phew -- this is not a simple thing at all, even when very close to finished.

 

There will be an announcement, likely in a few hours about the V5.8.0A decoder and demos being ready.   Also, the V5.8.0A0 decoder binary will be ready.   The difference between the A and A0 sound will be minor, but the A0 decoder will deal with complex sounds more cleanly.  I have the updated V5.8.0A0 right now, and am going to do some tests before uploading the V5.8.0A0 decoder. (Demo decodes for V5.8.0A0 will be coming in the timeframe of the V5.8.1G decoder & demos availability.)

 

It will be another day or so, perhaps quicker when the V5.8.0A0 demo decodes and the new, LF EQed V5.8.0G decoder & demos will all be ready.

 

John

 

 

 

[John Dyson]

Semi official announcement:

V5.8.0A demos ready, V5.8.0A decoder ready, V5.8.0A0 decoder ready.

 

The big audible difference between V5.8.0A transitioning to V5.8.0A0 is that vocals are more clean, less disturbed by the background music.  Better temporal (time-wise) behavior.  Otherwise, there is little difference on other fronts.

 

The 'other' materials will be coming tomorrow -- lots to do on other matters.

 

 

[John Dyson]

Still working on the V5.8.1 series, and because of the decoding results on V5.8.1G, had to move from V5.8.1G to V5.8.1H.

The current versions being demoed still have that persistent excess HF, but the V5.8.1H has that corrected, unfortunately not yet ready.   There are so many things that I needed to hear, but couldn't with normal EQ.  Unfortunately, I didn't even realize that the EQ wasn't normal.

 

I'd strongly suspect that V5.8.1H will replace all previous versions, with very favorable results.

 

The big difference between V5.8.0A0 and V5.8.1H is that the stereo image for the very high frequencies is a bit more wide.   Therefore, the strings in an orchestra will be more in their correct location instead of being pulled too hard to the center.   This change is mostly temporal, oddly there is more rolloff in the V5.8.1H, but since the timing is better, the highs are less obscured.  This strange behavior had been a confusing factor in the earlier part of the development.  This is far far beyond the days of simple tone control, but once the timing is all lined up, then normal 'tone control' won't cause much damage.   In a way, the higher the 'Q', the better'.  Low Q and 1st order EQ can really screw things up, even though the phase is more kind.  The lower Q EQ has an effect over wider frequency ranges, therefore precision is more troublesome.  Super smooth consumer tone control isn't too awful bad, high Q EQ damages only a narrow band, but has more severe local effects.   There are no really good solutions for 'just doing EQ', but combinations of EQ Q values seem to mitigate a LOT of troubles and minimal tradeoffs.

 

* The V5.8.1G decode was almost complete, but the HF EQ was too relaxed, leaving a bit too much HF.

 

The EQ pattern on V5.8.1G was a -3dB at 9kHz/-6dB at 18kHz.   Even though that seems strong, we are talking about a HUGE amount of pre-emphasis and de-emphasis in the original design.   Instead, with relatively better hearing this morning, the combination of: -6dB at 12kHz, -6dB at 18kHz, -6dB at 24kHz and -6dB at 30kHz sounded better balanced with the improved stereo image.  Remember that the -6dB at 12kHz is only 1/2 that amount at 12kHz, and the -6dB at 18kHz only reflects perhaps 1/2 of the 1/2 of the amount at 12kHz.   Note also the 6kHz offset between freqs.  This is used to make sure that distortion products will tend to cancel and not spray garbage thruout the spectrum.  There is a huge amount of FA designed-in cancellation and even more additional set of layers created by me for decoding.  The improvement in detail is profound with ZERO perceived side-effect.    If the frequencies are wrong, the temporal aspects will be seriously damaged.   There was something *wrong* with the V5.8.1G decode done last night, but sounded pretty good.  The 'H' version sounds better, more tame, better image and more clean.   THIS QUALITY PHASE MUST BE COMPLETED FOR THE SPEED UP, THEREBY INCREASING THE USEFULNESS.

 

We are going far far far beyond 'frequency response', and trying to reproduce the precise timing of the original recording.  There are still variations from the original, but all of this nonsense is needed because there was no original spec to work from.  If starting from a spec, all of the temporal aspects would also have fallen through just as frequency response/spectrum.

 

There is more and more consensus on the LF sound, and the HF sound is pretty close.  Where personally, I have troubles with LF judgement and hearing HF with any consistency, this has been a challenge.

 

Except for feedback from one more reviewer, which still needs consideration, it appears that the quality matters are now completely under control and ready to move on to the speedup.

There have been some premature 'finishes', but as there are comments about being 'complete', there have been more, very careful reviews.

 

I suspect that we are finally practically 'there' (again, except for one reviewer's comment about 'realism' that needs to be carefully considered!!!).   EVERY bit of constructive feedback is considered -- because it helps the project.   The criteria all along has been 'helpfulness' and not as much 'review for review sake'.    This criteria has sometimes caused conflict, but it was partially because of a conflict of goals.

VERY VERY CLOSE TO DECLARING SUCCESS, WITH EXISTANCE PROOF AS EVIDENCE!!!

 

 

 

 

[John Dyson]

V5.8.1H is ready, but I am not ready to announce 'officially' yet.

This should address the 'intensity' problem that seems to be hidden from my hearing.   In fact, earlier this morning this release sounded so dead to me that I almost stopped it.   Now, it sounds 95% correct, except maybe a little too much >15kHz?   This is manifest by 'crispness' and not the intense 'burning' as before...

 

Link: (should be the same):  https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

(A kindness that I ask for -- if you ever see 'full recordings' at any public links, tell me ASAP.  I do not intend to mistakenly distribute full recordings, but there are so many archives, it is possible to make mistakes.  I will correct such mistakes immediately. )

 

As soon as I heard the decoder results cleanly, the correction was simple and immediate, but I might have overdone part of the correction?

Here is what I mean:   The 6kHz range was PREVIOUSLY too strong, therefore causing some 'ear burning' and way too intense sound.

 

Part of the correction is a strange kind of EQ, can explain in the future, but part of the EQ is some mods at 9kHz, b12kHz, 18kHz, 24kHz and 30kHz.   It might be possible that the 24kHz and/or 30kHz mod should not have been done.  Oddly enough, even with my bad hearing, even changing the EQ at 30kHz with a Q=0.577 and Q=2 together is quite noticeable.   There just might be a little too much IN THIS V5.8.1H release  at the very very highest frequencies, thereby causing an overly 'crisp' sound, NOT a 'burning' like 6kHz does.

 

So, the ONLY real problem that I can detect when my hearing is transparent is an over 'crispness' at the highest audio frequencies, but not so much 'ear burning' as in almost all recent releases.   I cannot detect if the 'crispness' is real or not, but if V5.8.1H needs correction, the change is totally trivial, and mistake free.

 

In order to short-circuit any discussion cycles, I'll be starting a 'modified re-issue' of V5.8.1H that applies the possible change.   The actual V5.8.1H release will NOT change until we all agree on the correction, just that I'll be demoing the EXACT possible prospective change.   It will take about +1Hr to complete this modified *PROSPECTIVE* re-issue.

 

NO MATTER WHAT, this V5.8.1H should be damned close to what we had all been hoping for, and what we would have had >1yr ago if my hearing hadn't gotten in the way.

 

 

 

[John Dyson]

The sense of excess 'crispness' might have come from the slightly deficient upper bass.   I have corrected the upper bass in a test version, and now the sense of overly crisp sound is now gone.

 

So, there will be a full, but prospective release called 'V5.8.1J', that has the deficient upper bass corrected, and a minor change to the super HF (very very minor, but not crispness reduction).  These two, very simple changes will not include the crispness reduction.   If we find that the V5.8.1J release continues to need the crispness reduction, then we can do that as a 'final' step.

 

There *is* an 'M0' modified version of V5.8.1H already uploaded right now...   This modified -M0 version has the proposed crispness reduction (no other modification, no change to the upper bass), and it seems 'wrong' to me.   Feedback to the contrary is very welcome -- I do not fully trust my own perception.

 

The full, prospective V5.8.1J mods are too great to do 'after the fact' without risks of fidelity, so the V5.8.1J prospective release cannot happen until about +4Hrs at least.   When it is ready, I'll make a comment/unofficial announcement in the forum and also private messages as appropriate.

 

We are SUPER DUPER close to the end of this phase, and this sentiment is not premature like previous comments!!!

 

 

 

 

[John Dyson]

Those who have been patient about this must realize the troubles that the LF EQ has been.   This trouble is mostly about 'what should the freq resp be'?   We know that the recordings are NOT flat, but are they flat at a 'gross' or large scale?   I am starting to believe that FA recordings are flat at high signal  levels, just like a DolbyA unit is.   Being flat at high levels does NOT mean being truly 'flat' however, because there is processing more active at low levels.

 

It has been frustrating to try to 'tune' the decoder, because each of us has an idea about how a recording should sound.   This is especially confusing because most people have gotten accomodated to the FA sound (that is, the compressed sound of consumer recordings.)

 

In the last few weeks, finally got it through my 'thick skull' that the 'flatness' should really be tried.   Well, eventually, it was found that perhaps at *high levels*, FA might really be flat.   That, in a way, does seem to make sense.   The next release will  have nearly flat LF response -- even moreso than before.   The measurement method is now much more accurate than even one day agi...

Below is a measured LF response for a prospective next decoder version, look at the last number, ONLY at the change, not the absolute numbers:

(Basically, the gain is about 0.2dB higher at lowest frequencies than at 1.5kHz, and the curve is smooth.)   The first 'diff' used

the earlier way of measuring the response.   It is pretty clear that the earlier version pessimized the frequency response, but the

new version of measurement shows a nice, smooth response.

 

From this 'flat' EQ, we can develop boutique EQs for listenability.   The next result will be flat like this, or only slightly different.

(Look at the variation of the 'XdB diff' value, the last number -- this measures the relative response at each frequency range.)

 

LEVELS 1400Hz to 1500Hz
dB raw: -37.60 dB dec: -40.91 dB diff: -3.31 XdB diff: -3.61
LEVELS 1300Hz to 1400Hz
dB raw: -37.30 dB dec: -40.73 dB diff: -3.43 XdB diff: -3.69
LEVELS 1200Hz to 1300Hz
dB raw: -36.94 dB dec: -40.47 dB diff: -3.53 XdB diff: -3.71
LEVELS 1100Hz to 1200Hz
dB raw: -36.51 dB dec: -40.11 dB diff: -3.6 XdB diff: -3.68
LEVELS 1000Hz to 1100Hz
dB raw: -35.97 dB dec: -39.60 dB diff: -3.63 XdB diff: -3.63
LEVELS 900Hz to 1000Hz
dB raw: -35.33 dB dec: -38.94 dB diff: -3.61 XdB diff: -3.57
LEVELS 800Hz to 900Hz
dB raw: -34.62 dB dec: -38.18 dB diff: -3.56 XdB diff: -3.52
LEVELS 700Hz to 800Hz
dB raw: -33.88 dB dec: -37.37 dB diff: -3.49 XdB diff: -3.46
LEVELS 600Hz to 700Hz
dB raw: -33.12 dB dec: -36.54 dB diff: -3.42 XdB diff: -3.42
LEVELS 500Hz to 600Hz
dB raw: -32.23 dB dec: -35.63 dB diff: -3.4 XdB diff: -3.39
LEVELS 400Hz to 500Hz
dB raw: -31.04 dB dec: -34.53 dB diff: -3.49 XdB diff: -3.36
LEVELS 300Hz to 400Hz
dB raw: -29.68 dB dec: -33.43 dB diff: -3.75 XdB diff: -3.34
LEVELS 200Hz to 300Hz
dB raw: -28.22 dB dec: -32.29 dB diff: -4.07 XdB diff: -3.33
LEVELS 150Hz to 200Hz
dB raw: -28.53 dB dec: -32.60 dB diff: -4.07 XdB diff: -3.32
LEVELS 100Hz to 150Hz
dB raw: -28.44 dB dec: -32.14 dB diff: -3.7 XdB diff: -3.32
LEVELS 50Hz to 100Hz
dB raw: -29.81 dB dec: -32.01 dB diff: -2.2 XdB diff: -3.32
LEVELS 40Hz to 80Hz
dB raw: -31.63 dB dec: -33.20 dB diff: -1.57 XdB diff: -3.32
LEVELS 20Hz to 50Hz
dB raw: -37.57 dB dec: -38.29 dB diff: -0.72 XdB diff: -3.32
LEVELS 20Hz to 30Hz
dB raw: -46.07 dB dec: -46.61 dB diff: -0.54 XdB diff: -3.31
LEVELS 10Hz to 20Hz
dB raw: -53.32 dB dec: -53.92 dB diff: -0.6 XdB diff: -3.32

 

[John Dyson]

Oh my -- RIGHT, EXACTLY at release time, I found one of the very few low level bugs ever found in the code...   I'll have to defer the release until tomorrow.

 

V5.8.1M has a serious bug -- array out of bounds.   In one specific kind of operations, I hadn't checked for an array-out-of-bounds, and it was in the output EQ section.  The checks hadn't enabled  on the Linux version, but did so on the Windows build.  (For IP reasons, I don't use the STL library, but use my own support routines, everything except one library is from scratch.)  Once doing the 'final checks' on Windows, I had that evil program failure.  It was easy to find/fix, but all of the massive decoding results run on Linux were fatally tainted.

 

The LF EQ definition structure was right before the HF output definition structure.   Interestingly and irritatingly, the overlap caused an wierd kind of 'double EQ' that had minimal audible effects, but indeed did result in slightly erroneous sound.   I have not listened to all of the decodes, so there are even the possibility of glitches in the output.

V5.8.1M does sound good and is really near perfection, but not perfection-enough because of the almost embarassing programming botch.  (The code is vast, a few minor programming errors, even from the best of us, are to be expected.)

 

It is tempting to do the release, or show/brag about the results and results are *really nice sounding*, but unfortunately the results are also *wrong*.   Therefore, I won't even bother uploading the V5.8.1M output, and instead will build the V5.8.1N decoder and V5.8.1N decode results tonight.  This will essentially be a delay of 1/2 day, but I will *NOT* distribute output or a decoder with such a known pathetic  programming error, also will produce Heisenbugs.   Also, I will not stealth-like slip in a corrected decoder when I know that it does not 100% match the decoding results.  It is so easy to make that error even in the normal case.  I believe that erroneous audio processing algorithms are 'par for the course', but 'stupid programming tricks' are not to be tolerated at all.   I do 'stupid programming tricks' so seldom, this botch did happen at this time of an important 'proof' of success.

 

Of course, this will require another pass of manual tests, then the massive decode session (about 70 recordings.)   My guess is that, IF all goes well, and I am 100% available to finish up and upload the results, and all of the logistics personal time already scheduled, +15Hrs will be needed.

 

*PS -- once the error was exposed, the bug was found LITERALLY in 1 minute, but the cost in time is a LOT longer.

 

John

 

 

 

 

[John Dyson]

V5.8.1P release is ready...  Public snippets are ready, the rest is being uploaded, should be done in under 1Hr.

The delay from the 'N' release was needed to maintain integrity.  Even though the results appeared to be okay, even with the internal bug, fixing the code 'on the sly' and then distributing demos that were KNOWN to be inconsistent seemed to be a bad thing to do.  As far as I know and intended, the decoder V5.8.1P binary and the demos are totally in sync.

 

There had been some recent feedback about weak upper bass, so the EQ sequence was changed slightly, and the upper bass appears to be a little stronger to me.  (All of the LF EQ sequences look similar, but there are some changes in building block gain settings, and sometimes even optional frequencies where the building blocks might reside.  As mentioned before, this visualizes as something like Tetris.)

 

Snippets are at this location, the decoder is in the decoder subdirectory: (look for the V5.8.1P stuff).

https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

 

This has been hard earned, and has some improvements that intend to correct perhaps all of the persistent problems, esp the excessive HF.  I can make all kinds of explanations about my inability to normally hear the defect, but should now be at least 75% mitigated.   I should have recognized that some HF measurements that I couldn't quite understand probably indicated the HF EQ problem.  I *really* didn't understand what was going on.

 

Also, the timing correction, previously held back, now has been enabled.   The big difference with the large scale timing correction is that vocals become more clear &  prominent, but no real stereo image change.   The slight time delay errors caused some locality precision problems.   Those time delay/propagation problems should be better controlled.  The improvement on certain vocals is very noticeable, bordering on profound.

 

Unless there is still pushback on the HF, the decoder should be complete.   All internal capabilites  are now enabled.   There was also a bass problem, but I really do think that it should be fairly accurate now.

 

 

 

[John Dyson]

Just maybe, and I'd really like feedback on this...   There is a step upward of additional LF possible.  It would be about +1.5dB between 20 to 500Hz or so.  There are several various steps available, and I just cannot tell which is best.   It is damned close, but I keep getting 'mirages'.   Someone with more stable hearing can tell me if that small additional bass would zero-us in.

This kind of things seems to happen every time that I do a release, and the emotional change seems to change my hearing also.   Adding the +1.5dB is as simple as moving a building block.   I know that the shape is generally correct, just don't know which way to go.

 

I thought that it was done and correct, but now having second thoughts!!!

THANKS!!!

 

[John Dyson]

Even though the frequency response looked good, I believe that after resting my hearing that there still needs to be more bass.  Will be doing more measurements, and if there are ANY changes, it will be for an increase in bass.  Still must be reviewing the code/freq response.   I can even prove the response is rising towards the low frequencies, but still not sure.

 

As soon as I can, I'll try another version -- oddly, the measurements are correct -- I just don't know what has happened?!?!?

 

There was something broken during release, and I couldn't hear it...  Working on finding out what went wrong.  If I figure it out, a PROPER/CORRECT version will be available tomorrow monring.

 

 

 

[bogi]

33 minutes ago, John Dyson said:

there still needs to be more bass

Did you become such a feedback? I don't think so. IMO P has most bass since maybe the 5.7.1M version.

[John Dyson]

48 minutes ago, bogi said:

Did you become such a feedback? I don't think so. IMO P has most bass since maybe the 5.7.1M version.

Something is going to h*ll on my system.   I pulled back 'P' for now just trying to be responsible.  If it works for you, that is good and interesting - I APPRECIATE THE FEEDBACK!!!

 

This might show that there really is something wrong with my computer system.   I really don't want to be disappointing to anyone as I have disappointed people for a long time.

 

My measurement tools are showing extreme weak bass (-6dB instead of -3.5 or -4dB in relative terms.) Last night, before I started the decodes, the bass was correct.

When I rebuilt 'M', which also had reasonable bass (but a bit less), the bass today was insanely weak also.   Both the 'P' and 'M' codebases were bad.

 

It just magically started working very poorly.  I noticed the problem with listening to the decodes today, they were shrill without bass, but they were okay early this morning.

 

I greatly appreciate your feedback that the bass seems correct (or nearly so.)

 

I am really panicing, because something is really wrong, perhaps something wrong with my development environment.

I have 'P' ready to re-upload, and it SHOULD be okay, but again, my tools which showed GOOD last night, shows BAD right now.

 

PANIC ATTACK!!!!   Will try to figure it out ASAP.  First step: reboot!!!

 

EVERYONE: Please be patient.  Honestly, the decoder was previously working SUPER WELL -- perhaps only minor issues needing to be adjusted.

I hope that @bogi's observation is absolutely correct (probably is correct), and my machine (or me) has gone temporarily insane!!! :-).

 

ADD-ON:  I moved to my internet machine only (bypassing the development machine where the measurements were odd), and agree with  @bogi's observation about the bass being stronger/better on 'P' than 'M'.   I am rebooting my 'X' (big) machine, and going to re-evaluate from scratch.  The bass numbers were measuring were 2dB weaker than yesterday -- on exactly the same software.

 

This makes me wonder if one of my system libraries on the 'X' machine got corrupted?!?!?!   This is weird, but I promise an answer soon.  It might be as much as 24Hrs because this must be carefully resolved.    I owe loyalty and integrity to who are helping and interested in the project.   This means that the resolution might take a few hours.