'FeralA' decoder -- free-to-use

[John Dyson]

Just got some freedback about 'RELEASE8', and the feedback was paraphrased:  sounds a little like a remix (on some Fleetwood Mac examples.)

 

After thinking it, and knowing the processing -- his comments are telling me that the descrambler might be set a 'notch' too strong.   There is a series of mutually big steps in dBs (but manifest as small changes in audio) that can be used to change the intensity of the highs.

 

FA encoding 'rounds off' the highs with its very interesting kind of processing.   The decoder is written with the understanding that 'standard components' were used in the encoding process.   These 'standard components' end up being the 'steps' available to change the sound of the highs.

 

Even if the steps are 10% too strong, it appears to be very noticeable to those not accomodated to the sound of the decoder.

 

Right now, the decoder is running as 'RELEASE9', where the decoding will be stopped now.  RELEASE9 still is 'too strong'.

After thinking about the correct change, and listening carefully for A/B comparisons (which sounds more natural), then I'll start a 'RELEASE10' tomorrow.

 

The decoder is very close to what it should be, but hasn't made it yet.   IT LOOKS LIKE A LITTLE LESS 'descrambling' is needed....

When the decoder is complete, even though not everyone will like the sound, it should replicate the before-FA versions of the recordings.

 

John

 

[John Dyson]

After evaluating the recent set of comments, I found a few 'grumbles' in the HF sound, which happen if the HF doesn't have enough descrambling.   Likewise, if there is too much, I could recently (last few weeks), the sound gets a 'stretched' sound.   Frustratingly, the 'stretch' manifestations seem to happen only when 'extreme'.

If the signal is completely 'squashed' by the FA encoding, then the 'grumbling' or 'stretch' sound is also hidden.  The 'grumbling' sound seems to happen as a kind of 'beat' like an old SSB reciever, but the 'stretch' appears to be a direct kind of distortion.    It is a lot like a well designed super-fast compressor is used, many of the artifacts normally associated with dynamic range compression aren't as bad.   The same thing appears to be true about FA encoding.   When the 'compression' is corrected inaccurately, then a few artifacts might leak through.

 

Why is John only noticing these 'artifacts' after years of work?    It is because the descrambler is starting to match the original scrambling, and the distortions associated with the operations and the 'beating' between the scrambling and descrambling operations become noticeable.    When the descrambler/scrambler are close to each other in settings, then there appears a kind of noticeable distortion.   When far-different, then the distortion is also hidden, like with the FA encoding itself.  THE GOAL FOR THE DECODER IS NO LONGER 'practically perfect', but instead is 'nearly perfect', at least one step better.   Reason is that 'practially perfect' or 'close' is not good enough, given the processing steps needed.

 

So, these 'bugs' are the result of left over processing, only noticeable in detail when all of the other several layers are precisely correct.   The descrambler itself has approx 20 layers, but only about 15 of the layers are critical, and the problems being resolved right now are about 7-10 of the layers (starting about 2-3kHz or so.).

 

With current test 'releease11', it still sounds like there might be the very slightest amount of beating/growling, only noticeable on parts of the signal that is above about 6kHz.   There are some dynamics 'tricks' needed at 7.5kHz, 6kHz and 4.5kHz.   Parts of the 'tricks' might not be correct, so still trying to make it perfect.

 

John

 

 

[John Dyson]

Astoundingly good NR now -- listen for the mostly constant noise floor in the decoded version...   Nearly perfect!!!  Ever so slight noise modulation -- given the HUGE hiss in the original version, the small, very small noise modulation might be excused...   Note also that I am investigating the tonality of the piano.   I grew up with a piano, and the sound seems just a little hollow...    Also, the Sax is a bit hollow, so that argues for a response problem (dealing a freq response problem is NOT like a 'parametric equalizer', as it has taken me a long time to learn.)   If it is a bug, I have some ideas to correct it...   When listening to the entire recording, the dynamics are just a bit distressing near the end -- an uncompressed piano being played farily strongly can be moderately loud, along with the Sax.

 

* OTHER VERSIONS WITH CLAIMED GOOD NOISE REDUCTION PALE AGAINST THIS VERSION!!!

 

Otherwise -- ASTONISHING!!!   It suprised even me...  (otherwise wouldn't make such strong claims)  All together, the NR seems a bit better than DolbyA, I am not sure if it approaches DolbySR.   Hissy material, DolbyA encoded, seems to have more hiss than the result here.

 

Both from the Brubeck album 'Time Out' (same one that contains 'Take Five'.

 

RAW. converted from very high res source:

https://www.dropbox.com/scl/fi/4lcj2r8nbzqcq3174kjp6/04-Three-To-Get-Ready-CDRAW-SNIP.flac?rlkey=gxkvk4vriqmu7vybxjmuoxkhm&dl=0

 

Decoded using the V20V26 test version of the decoder:

https://www.dropbox.com/scl/fi/qk04zkgvezfmfmw1qdq80/04-Three-To-Get-Ready-V20V26-SNIP.flac?rlkey=8htqedzr0g6vpdaot805k7fyh&dl=0

 

So, with the known bugs still being resolved, the 'bugs' not yet determined, a release with very very good accuracy should be coming.

I'll be on 'vacation' for a few days, but back soon!!!

 

John

 

[John Dyson]

An improvement that handles the natural rolloff of the HW:

-0.09dB at 24kHz

-0.18dB at 30kHz

-0.35dB at 36kHz

Believe it or not, this slight rolloff is critical for proper operation...

At this point in the decoder, anti-aliasing isn't utilized.   However, there IS some rolloff on purpose.   Given the rolloff of DolbyA units (much faster than the rolloff just added), that rolloff is already accounted for.   My suspicion is that the rolloff above is needed because of other hardware and the rolloff of the stages in the descrambler.

 

The changed version below is ONLY the rolloff stated above.   The effect of the super-high frequencies comes from the descrambler itself.

 

Slightly imiproved example (starts with the same as the previous post):

https://www.dropbox.com/scl/fi/8m5teuth8h7tux8l8uuxg/04-Three-To-Get-Ready-V20V30-SNIP.flac?rlkey=v4q51guhu7592ts9ai4tmkisa&dl=0

 

In a few days, I'll be iteratively doing another pass through the descrambler, making the bass/midrange slightly more accurate.   There are still useful 'tells' that show errors, but they are getting smaller and smaller.

 

John

 

 

[John Dyson]

The results are truly approaching 'High sound Fidelity' of the 2000's, but also easily produces High Fidelity associated with the 1980s.      The decoder is still not refined , it is also getting trickier and trickier to do a 'release', simply because of the complexity and my lack of mgmt organization.  Finishing and refining the decoder has required patience, with the work including listening and making changes needing much more time than in the past.

 

*  I'd expect that the earliest that a partial demo set will be available would be Saturday Noon (the earliest.)

 

I will make demos available again, especially with the helpful/well received 'A/B/A/B' demos, with 10sec, 20sec and 35 sec.    Also, just might be making a minimal, very small select few for casual demos before the massive demos.

 

Any slowdowns for the next few months are for LOGISTICS, 'organizing', and looking into improving the product for use on Windows. 

 

With more TLC (tender loving care) care, hands on, being more careful/dliberate, the sound will be noticeably improved, even with the expected very small changes in the decoding system.

 

These matters are addressed:

 

* A more natural sibilance, sounds less brassy.

* Noticeably more realistic pianos!  (I think REALLY, this time.)

* The pumping associated with older, hissy recordings should be even better controlled.

* stereo image, location of instruments, etc should be, HOPEFULLY, and VERY INTENTIONALLY SHOULD BE IMPROVED!!!!

 

Making the sound of a piano correct can be challenging.   This isn't just gain, but also varying gain.

I think that HF from this one is likely finally closer to correct!!!!

 

 

It can be so frustrating at this point.    Even after doing reviews of perhaps 10 different test objects, I am not 100% sure that the current demo is correct.  It will probably take a big part of this evening to have finally settled on the version of V20V that will be demoed, hopefully WILL be the V20V release...    I don't care about 'numerology', so if another subversion is needed, moving from V20V to V20W, then it is okay.   However, I do believe that this V20V is the best good

 

I truly believe that the decoder will almost always be desirable to use for the reasons of sound character & quality.

We should be getting close to being able to depend on the decoder, but admittedly, not quite there yet -- but CLOSE!!!!

 

Sincerely....

John

 

*Even when the quality issues are alll resolved, we still have CPU usage/amount of processing/etc.   Once we have a 'perfect' decoder, maybe a math genius out there somewhere might be able to help with making the program efficient.

**Thanks so much for being patient -- YOU will benefit from a good working decoder...   I'll just feel a little better that I had helped!!!

 

 

[John Dyson]

Working on the 5th or 6th iteration since the previous posting.   It takes lots of work, especially if trying to 'wrap it up', instead of producing another set of demos. This message was originally very long, then 'shortened'.   The original version was full of incomplete technical details, the partially correct details only confused the situation.

 

There is a series of three items (all interrelated, each one mutually modifies all three.)   Correcting the items below isn't a huge amount of work, just very tedious and need to be patient for times of good hearing.

 

 

An important take-away from the longer version of this message is that making A demo of several good examples is unlikely for today.   I am going to try to do some demos tomorrow.   If the decoder is *really good*, but still might feel uncomfortable, I'll make a short set of demos.    The probability for at least a short set of demos is pretty good for tomorrow, and really good for day-after-tomorrow.   I'd love to do a short-set of demos tonight.   If the code feels dead-on stable, and after significantly more testing also creates good results, then I'll consider starting a short set of demos as early as tonight..

 

Here are the Issues, actually MUCH simpler now than the description might suggest...   All of these incomplete descriptions might use lots of words, but the changes aren't all that big, and IN ALL CASES, there has been no real drift in the settings of the descrambler.     It SEEMS like the optimum settings for the descrambler are carefully

 

1)   Been worried about the balance where previous versions seemed to be missing middle/upper bass (not middle freqs.)   Reviewing this carefully.   Big improvement by removing almost all direct manipulation of HF response inside of the descrambler.   Investigation is active.   This item might be just about ready to finish. A few hours a series of ill-considered changes were made,

 

2)  Really good news that both of the final, actual DolbyA emulations are fully enabled emulators.   In some applications, the MF band (80/120Hz to 3kHz) is disabled, and in fact, it seemed like the midrange needed to be disabled on one of the final DolbyA emulations.   Now, after a lot of testing/verification -- the full DA emulations are now fully enabled.   THIS IS A VERY GOOD THING, and seems to be mitigating some of the problems with '--coff=xxx' below.  

 

3)  Been reviewing the calibration offset (--coff), trying to find out if the default of '--coff=0.0', and it seems like --coff=1.815 might actually be the most correct setting with a choice between --coff=0.0 and --coff=1.815.    I am doing lots of verifications and very sensitive listening tests, most of the A/B comparison being done only 10-20minutes after starting work.    All of the most serious A/B comparisons need to be done when hearing is most consistent and most accurate.  The accumulation of all of the other 'bugfixes' and the important enabling of both of the full DA emulations.   With most of the other settings really being correct, it will be easier to find the final/correct --coff=xxx.    The biggest effect of '--coff' changes the character of ambience noise/room effects/wide dynamics instruments, etc.

 

 

The next demo will be even better than most previous demos.   The current 'test code' is really good (prob better than any previous demo), but I am still a little challenged by the '--coff=' choice.   The 'programming' is correct, but I am not 100% sure about the settings for the threshold...   Think about it -- internally, errors in the 0.0005dB range can have negative consequences.   Admittedly, not all settings require 0.0005dB accuracy, but many do.    The '--coff=' thing has two layers of 'accuracy requirements'.    The first layer is just the 'general region'.   For example, the suspected '--coff=1.815'  might really need to be '1.815' or even '1.75', but still needs to be more testing, review and evaluation.    Adjustments aren't worrying right now, it is just tedious to find the exactly correct setting.   Depending on the setting, the specific setting and type of setting, the accuracy might need to be +-0.0005.

 

 

If there are any major 'breakthroughs' that will allow some demos with high expectations for quality, I'll definitely let you know.

 

It is really really really time to finish this part of the program, but it must be 'correct' before thinking about any other related things.

John

 

 

 

[John Dyson]

The development work this weekend is focused towards the decoding mode for DolbyA & running the decoder on Windows.

All of the serious technical work is complete for DolbyA, and historically running the decoder on Windows hasn't been a problem, just that there has been no testing for running on Windows.

 

Most of the challenge will be for all of the development installation and correcting any unchecked programming damage done over the last year or so.

 

It is expected that SOON after this weekend, the decoder will run on Windows again.

Given that this is a major family & religious holiday,   there might not be enough time to complete the update. but unless this donated, used Windows PC has a serious installation bug, the decoder should be able to run on Windows by Friday 5 Apr.

 

The current test version V20V72 does produce results that sound pretty good, and seems to match the several raw, never-FA recordings in my archives.   There aren't enough never-FA examples to make this a simple A/B testing from the standpoint of Never-FA vs. Decoded-FA.   However, it is possible to do lots of testing, and the comparisons must be decoded-FA vs. encoded FA normally sold to consumers.  This means that along with my hearing being fairly unreliable, I'll have to be careful on this upcoming release (intended to add back the Windows capability.)

 

There are 100's of potential mistakes, but hopefully serious problems won't be encountered....

 

John

 

[John Dyson]

Wow, got a software delivery that JUST MIGHT be from heaven...

 

Ever heard of 'CLAP'?    It is a plug-in scheme that might be good enough to mesh well with the decoder.    The decoder has troubles because the audio packets are not tracked and managed well at all.   This means that on a given song, there might be a few ms error in the input/output timing.    After the upcoming 'Windows' test release in the next few days, there will be a beautiful version of the FA encoder in a week or so.

 

Once the GOOD FA decoder is uploaded and reviewed and at least privately recognized, I'll look at the CLAP plugin stuff   This might be 'really good' goodnews.

 

So, I have found that 'CLAP' might be very helpful for the project.   This might lead to better integration with other 'plugins', and MAYBE even be able to strip out the horrible sample rate conversion code!!!

 

I am hoping in the next week:

* THE great FA decoder along with DA mode.

* Ability to run on Windows.

 

After next week -- perhaps 2 or 4 weeks afterwards:

*  Integration & interoperability with CLAP plug-in mechanism.

 

More good and functional stuff should be coming in days.

John

 

[John Dyson]

I have had to a 'retry', because the 4.5k to 7.5k problem is real.   I just couldnt' tell, and there are about 5 choices for the settings in that region, all spread  in about 2 spots in the code.

 

There'll be an update in the next day.   However, when you listen the demos, I think that the progress will be very obvious.

(I thought that the decoding results were just a little 'too clear'.)

 

John

 

MESSAGE SUPERSEDED:

 

Sent to the parties interested in the FA (consumer) mode of the decoder:

 

Good stuff (I hope.)   The middle HF might still have a bit of trouble, but might also be my headphones.

A LOT, I mean A LOT of corrections, mostly coming from even more understanding about the need for exactness and simply not knowing the algorithms.   The reverse engineering has required lots of iteration, far far beyond what might be tolerated by most developers, and certainly more demo iterations than most reviewers/potential users might tolerate.

 

*  for those interested in DA, FA is at least 10X more complex than DA.   There is a lot of magic in the FA mode, including the 'dispersive processor' -- infinitely fast attack/release compressor/expander!!!

 

Unless there are very specific bugs described by the reviewers/potential users/friends, I am focusing now on the Windows version of the decoder.   There is a potential new user that REALLY NEEDS the recent Windows version of the decoder, so I MUST focus on the Windows version or might be a fatal mistake.

 

V20V85 pointer below.  The *LINUX* version of the decoder is in the root of this link, but Windows should be available biy the 13-14Apr.   Remember, for reasonable quality, it is important to download instead of use the Dropbox player.

 

https://www.dropbox.com/scl/fo/6isnqj9i3cpk5oq4rmzok/h?rlkey=ai13rltafikaej7gvjrc35x87&dl=0

 

Enjoy, esp if you believe that the sound is good.   Except for my worry about the 4.5k to 7.5k range, it should truly be PERFECT (I mean really good.)  Just take a listen to the almost 100% effective noise reduction on material that allows it.   My worry about 4.5k to 7.5k range might be specious -- those who normally correspond with me know that my hearing is attrociously unreliable.

 

 

From the demos, give these rather profound examples a try.   These are 20 second A/B/A/B, where the sequence is 'decoded-orig-decoded-orig'.   This part of the message is a clipping from a private message to someone else, so might be a little more odd than my normal postings....

 

LISTEN FOR THE NOISE REDUCTION ON THE BRUBECK RECORDINGS OR the Carpenters example below....

 

Brubeck (Three to get Ready):  https://www.dropbox.com/scl/fi/2kv9jz0v9vnca6g3ukaqh/seqdemo-04-Three-To-Get-Ready.flac?rlkey=4cr4wrdqt30xkc7rr1o2sgwj6&dl=0

Carpenters (Bacharach Medley): https://www.dropbox.com/scl/fi/nzmfagru51aub5p2zxyo1/seqdemo-09-Bacharach-David-Medley.flac?rlkey=xwvjuivwgft5iovwi2m664gen&dl=0

 

Whenver listening to the demos, IT IS IMPORTANT TO DOWNLOAD FIRST.    The online  Dropbox player has serious quality problems.

 

 

 

Sincerely and with kindness...

John

 

 

[John Dyson]

The planned release had been delayed a little, not caused by technical issues alone.

There is a change in active goal as of yesterday (now).   There will be NO MORE search for more bugs, instead restart usability improvements after several years.

 

Summary of 'too long' message below:

This has become a 'forever' project, without useful results.  Time to 'finish' with mostly very good quality, even though the goal of 'practically perfect' is not met.   Most of the time, the technical results show an improvement over the original FA, just not quite  'practically perfect'.   The quality has been improving, slowly.  Unfortunately, it has been 4-5 yrs since there has been a usability improvement along with the Windows version languishing and not been updated for perhaps 6mos.   After the current 'problem/solution/fix', non-fatal changes will be deferred into the undetermined future.   The first focus after the technical 'finish' will be to create a Windows version, then a release with 'high technical quality'.   'Quality issues' that don't explicitly distort or problems with exceptionally encoded recordings will be logged, but not corrected.   Only obnoxious problems will be considered for correction.

 

I don't know when this goal will be completed, but will be ASAP.

1) completing the last technical fix, 2) doing the demos/quality control, 3) creating the Windows version, 4) writing at least a usage guide again

 

The commitment to the above steps is driven by the concern about infinite delay, but also other real world practical considerations.   I have promised the DolbyA mode only this upcoming end, and I hope that I meet it.   The FA so-called 'decoder' needs to be made usable, with NO distractions.

 

Demos should be coming soon, because the specifics for the Windows version and 'usage guide' are almost independent of the decoding operation.

Not 'finis', but certainly at least temporary change in direction.   The project as a whole is NOT DONE!!!

 

Sincerely and regrettably... 😥

John

 

-----------------------------------------------------------------------------------

 

Rest of mssage that is 'too long', not as critical to read, but some technical details.

 

After realizing that the active search for 'decoding' bugs has been 'forever', but the project cannot be  'forever'.  Given this dose of reality, the release goal has to shift a little towards usability, but still with ongoing improvements as they become obvious.   Processing bugs will no longer be a relentless, tedious, time consuming, 12-20Hr/day, hearing damaging search.   This is NOT 'quitting time', but more like a less active search for audio bugs, and more active search for usability issues.   The project cannot sustain any more delays;  the project is probably already damaged beyond repair.

 

Background: Part of this change of strategy resulted during a desperate attempt at a good demo release and Windows version.   New quality improvements were found unintentionally even early in the most recent weekend (Apr 6 approx), but  the results just before were already deemed 'good' by many of the several reviewers.   This encounter was found during some minor changes/cleanup on the pilot processing. The kind of processing changes needed to make the improvement made it obvious to me that the last bits of  complexity will be almost impossible to find & correct in a practical amount of time.   A further, ongoing delay seems to be wrong-headed when we already have something that produces very reasonable signal improvements.  It IS time to declare a 'time out' for major 'decoding' improvements, while focusing on useability.   This is NOT 'I give up', but it is finally time to change the direction towards for a few months.   The last real 'usability' improvement happened a LONG time ago.  In fact, the last 'usability' improvement happened when the 'decoding' ability started changing from 'totally manual approximation' to 'actually attempting to decode' (years ago, many people have given up their faith and/or patience about the project.)

 

In the last few weeks, I did find some better examples of pre FA recording LPs, but many tracks were manually 'mastered', IMO 'distorted'.  It might superficially appear that access to a few LPs might be enough sources for further development, but things are not *that simple*.   Many of the tracks on the ancient examples were 'manually mastered'.  The manual mastering is often WORSE than the 'automatic' FA encoding.   Sadly, there might not be enough really good examples to zero-in perfectly.  Frankly, even with the additional examples, solving all of the problems still seems to be 'forever'.   Traditional 'mastering' can sometimes be terribly damaging.

 

There have been some, more than one, private suggestions that I am too much of a perfectionist, but one should understand that the original goal was 'perfect', with a tolerable result of 'practically perfect'.   As of now, the goal is changed to 'significant improvement most of the time', where this 'significant improvement' might be nearly the same as 'practically perfect'. (I almost laugh when one person called me a perfectionist -- but perhaps instead best described as 'tilting at windmills' or  'chasing rainbows'.)

 

The recent results over the last few months would have been less improved without finding and understanding the 'pilot' aspect of the signal in the recordings.   The 'pilot' is composed of modulation products that are probably unintentionally maintained while creating *digital* masters.   Analog copies lose a lot of the 'pilot' signal sometimes making the 'pilot' useless, or even worse than useless.   This 'left over' distortion is clearly almost directly from the raw 'FA' track, but all together doesn't sound as good.   When one aspect of the track is 'decoded', while another aspect is incorrectly decoded, the 'dissonance' sounds NOT GOOD.   IMO, this happens in the <10% of cases (actually, I have found just a few tracks that sound bad.)

 

Being part of the decoder that does come a closer to 'practically perfect',  DolbyA signal capability is good enough that it is useful, much better than it was 5yrs ago.  For normal consumer purposes, the DolbyA decoding ability is a curiosity, and isn't directly applicable.   There have been several inquiries about the DolbyA signal capability, and it is wrong to continually defer availability.   As a part of the usability issues, the Windows version of the program needs to be updated.   In comparison, the processing results of the most recent 'Windows' version is best described, in comparison, as garbage.   Gotta make it not-garbage.

 

Given these frustrations, until otherwise determined,  without being 'practically perfect', the  'FA' decoding capability cannot be called 'decoding' unless in casual use of the term.   The so-called 'decoder' will most of the time be capable to mitigate a lot of the FA distortion artifacts, perhaps sometimes even coming close to the goal of 'practically perfect'.   However, as a matter of judgement, it doesn't seem to be 'good enough' to be called a 'decoder'.

 

It seems like a good idea to produce a release with the best results so far.   The so-called 'decoder' will continue to be developed, but it is time to produce something that is not quite 'practically perfect', instead will be 'practical', still reliably creating good results on recordings that still have a 'pilot'.   Even if the 'decoder' is temporarily no longer being improved, some of the techniques need to be disclosed along with the decoder source being memorialized.   Cleaning up the source and adding up-to-date comments will take a few weeks.   The 'memorialization' will be done after at least a few usability improvements.

 

The development/search for new bugs is stopped as of yesterday, and the cleanup and correction of the new pilot findings will be completed before any new release as-is.   The release will contain a windows version.

 

I have tried to change course for the last several months, and I delayed it as long as possible.

More to come, but after the new release, the direction will be different.  Certain things need to be 'wrapped up', just in case before there is a time that I cannot make more progress as the developer.

 

Going to finish this sucker, even if it might not perfectly meet the goal.

John

 

[John Dyson]

Project still active, but both personal delays and quality issues on the decoder.

 

There has been a persistent 'pianos don't sound right' problem.   I concurred, but didn't fully avail myself of various never-FA recordings that I keep forgetting about.   A/B comparisons are critical!

 

The 'pianos' problem is mostly corrected, might even be fully corrected.   The primary software bug has been related to the threshold on the DA layers.   There is a regular pattern in the thresholds that sound 'almost correct'.  This pattern tends to be related to multiples of 1.5dB and 5dB.   The settings in previous versions were in a 'rabbit hole', incorrect but seeming plausibly correct.

On older versions, the DA thresholds were set too high, by approx +12dB, which shifted the HF tilt by a few dB, and gives a more clean middle HF.   The shift in tilt was also beneficial that some of the HF EQ isn't needed any longer.

 

I know that things have been slow and delayed, but part of the new 'release' or 'demo' frequency has been to mitigate further public mistakes.

 

Recent attempts (all attempts) to release working software came from a bit of a dilusion, but also so much work has been done and invested into the project that it 'must be complete'.   It IS getting closer because the architecture is really correct, just that the myriad of settings is also mind-numbing.   The 'threshold thing' is the least obscure kind of error, there are so many obscure interations that looking back to the beginning, it makes me wonder how the program has gotten so far towards completion.

 

Will let you know when something interesting has happened!!!

Sincerely,

John

 

[John Dyson]

I'm back with a few comments before another attempt at a 'final'.

 

The problems of descrambling are being better understood, most important bugs were excess expansion in the midrange along with the  'phase swaps' being at incorrect frequencies.

 

FA is intended to be broadcast or placed on media.   Peak values become very important, and FA is a package that does all kinds of 'nice' things, including IP protection, 'automastering', and also some limited control of peaks.

 

The most important/difficult challenge has been the 'phase swaps', which on average will tend to decrease peak signal values and help with the 'automastering'.   These 'phase swaps' are a subset of randomizing the phase to help control both average peaks and symmetry of the signal waveforms.   There is an old problem on non-processed AM radio, where some announcers voices weren't able to be broadcast very loudly, simply because of the asymmetry of the waveform of their voices.    Of course, one could swap the phase of the audio.

FA provides a partial randomizing of the phase, but with a little audible signal damage.

 

These phase swaps appear to be 221.3/5 and 221.3, 221.3 and 221.3*5, and a few more.    Finding the location of these phase swaps requires arduous listening to at least several recordings of several genres (I will not claim *many*, but it seems like it is.)   When doing these A/B comparisons, it requires monumentally stable hearing and listening for the ever so slightest detail, but even then some recordings will seem to degrade when most will be improved.

 

I have been 'down' for about 1wk, but will be able to start wrap up work on these final, realtively new issues.   I have been very poor at these final choices, perhaps the most embarassing is the excess MF expansion, which appears as the center of the spatial field raising spatially high -- not good.   It sounded right to me, but I have been summarily corrected on this matter.

This excess MF expansion was an egregious fault, especially when the goal is 'reconstruction' or 'recovery'.   As I had claimed before, the goal is NOT 'sounds good to me'.

 

The 'phase swap' correction seems like it might always be imperfect, but close enough that there IS an improvement.   The phase swap along with the associated descrambling is important for the most complete degarbling ever.   (The phase swap and discriminator based descrambler are integral, but seemingly coded as separate entities.)  Because of the structure of the descrambler growing and changing over time, the code isn't horrible, but is incomprehensible without external documentation.

 

All in all, the sound will be pretty good.   When I am able to make the final choices, most are related to the above along with a few EQ changes because of changes to the 'phase swap' mechanism, there will be a rather uncompromizing 'final' release.   Importantly, I MUST stay away from ABBA Gold -- it is a 'Dogs Breakfast' when it comes to quality.   Some kind of 'bad touch' has been applied to it, and for the life of me, I haven't been able to remedy the mostly HF distortion, even though the decoder can make some improvement.   So, that 'guilty pleasure' is 'over' until the release.

 

This has been a stimulating challenge, but has dragged on too long.   If the decoder is ever internally documented, it will be a good basis for those with interest in the future, perhaps 20-50yrs from now when the true masters are lost.   The decoder will still see minor improvements, perhaps minor EQ corrections or correcting a bad choice for the phase swap gains or frequencies, but the structure is definitely close to the inverse of encoding.   Also, the DolbyA emulators need SERIOUS cleanup, and there are a few quality problems with the digitally simulated analog feedback loops.   The quality is probably almost as good as using two different DolbyA units for encoding/decoding, but is not as precise as I know is possible.

 

FUN FUN FUN...

Still a little cleanup to do, so willl keep you up to date -- soon.

 

John