'FeralA' decoder -- free-to-use

[John Dyson]

So far, the feedback has been generally positive -- except...

There are a few minor freq resp mods with the HF/LF, very very minor...   All suggested changes seem to bring the objective measures to a more neutral setting, which is a good thing.  I don't think that any of the positive comments will need to be rescended, but will beg for cruel honesty if there is a regression in RELTRY70.

 

On the other hand, the timing sucked in RELTRY50, but I didn't realize it.   When working on the demo release, I was so focused on 'freq response' being the correct shape, but e time delays were off, therefore hurting the stereo image and apparent detail.   The timing errors seem almost impossible to notice until hearing the results with proper time delays.   RELTRY50 sounded good to me until hearing the RELTRY70 prototypes (actually, we are at RELTRY58 right now).

 

I won't have time to run the entire set of demos tomorrow, especially preparing them for a demo release. So, tomorrow night my time,  I'll upload a short set of demos for picky criticism, perhaps 20, most selected from the '95', but a few that aren't in the normal demo series.   The new demos will almost be fantastically better than RELTRY50.   These RELTRY50 were very helpful,  the upcoming RELTRY70 shortlist will hopefully be reasonably close examples for the upcoming public demo release.

 

John

 

[John Dyson]

Been working on putting together the decoder for interim (public) demos, for before the actual release.

Found a MAJOR quality improvement, seperating the 'pilot' from the 'signal' quite a bit (a lot) better.

 

I am pretty sure that the demoed quality will be a surprise -- because it was for me...   The biggest quality improvement in a long time, but so trivial it wouldn't be correct to call it a 'breakthrough'.   In some ways, the 'pilot' is garbage, but in other ways is important for proper tracking.

 

It seems like a good idea to run all 95 demos this time, and also a few full discographies if people might be interested.   No matter what, the 95 will be run today.

 

John

 

[John Dyson]

Been having *great* success with the early-than-planned demo, but been trying to decide the amount of dynamics processing.   Also, it has been a bit tricky to pass the 'pilot' through the EQ steps while also utilizing the EQ steps for 'other things'.   There is a small window through which the pilot affects other discriminators, blah, blah, blah.

 

This version should be very significantly better than RELTRY50 -- much better.

 

Bottom line, been getting really good results, but not quite a 'centered' result, perhaps until now?.   I am dithering between 'close' to the 'zero error' point, or 'exactly' to the 'zero error' point for the pilot EQ chain.   The EQ chain is a chain, and has elements that have to line-up, but are made up of seemingly almost unrelated freqs.   If the chain doesn't line up, then the sound suffers.

 

The bona-fide demo version is V20B-RELTRY69, but the EQ block choices are bouncing' around when trying to decide on the best settings has pushed the versions up to V20B-RELTRY69F.   Now, most of  these versions are mostly inconsequential, might only last 5 minutes, or might last an hour or so.   The only consequential version is the last of the RELTRY69 series, where 69F sounds pretty good and follows all known rules.   My worry is that the dynamics processing *might* be one step too strong, making it not 'perfect', but can still sound good.   It will take a lot more work to make the result 'canonically correct', but could probably still be judged 'correct'.

 

A new set of demos is being started right now, version ID of V20B-RELTRY69F.   When the results are 'good enough', then I'll upload them.   69F might be 'it', but it is possible, NOT LIKELY, that it will require 2-3 more tries.   This is truly in the world of adding/subtracting a building block and doing A/B comparisons.   I don't remember ANY 'tweaking' being done today, but just adding/removing EQ building blocks and trying to find the optimum 221.3Hz related frequency steps.   Very tedious.   (Tweaking is for matching HW compatiblity, resistor values, etc -- there is now a procedure for the project that helps to zero in on correct HW compatible values, without 'tweaking'.)

 

If this 'F' version isn't too awfully bad, sounds very good to me (it will have to be very very good), then I'll stop the iteration process and upload so that the demos will be available close to the beginning of the weekend.   My guess is that the demos will take about 4-5Hrs including .flac conversion, creating A/B comparisons, etc.   In order to avoid wasting much time, I'll start reviewing the demos about 2Hrs into the creation process so that we can 'recover' before all of the 4 Hrs is spent.

 

John

 

[John Dyson]

Progress report for V20B-RELTRY69....

 

I do plan to upload V20B-RELTRY69F, even though I cannot do a complete review because of drifting hearing.

It will still be at least several hours before upload can start.  Even A/B comparisons are totally unreliable, so there will be some intentional 'slowdowns'.

 

V20B-RELTRY69F does seem *really good*, but impossible for me to judge in the last few hours.   On the other hand, when the demos are uploaded, kind comments about 'too much HF' or 'too little/too much' bass will provide guidance to move some of the building blocks around.   There are a few immediately available settings that can do a first order change.

 

Expected complaints might be:   'dull HF', 'crinkle in the HF', 'boomy LF', 'thin LF', etc...   Many more possible useful criticisms.   For those uncomfortable with precise complaints, just tell me that it seems 'too much' in the HF or LF, or 'too little' in the HF or LF.

 

I am preparing for the results not being perfect.   The results are not expected to be 'perfect' until RELTRY70 and/or V20B-RELEASE.   There are still a few more steps, and the steps do take time, in fact LOTS of my time.

 

Next status for RELTRY69F will be:

 

A) Eventually, it is found that RELTRY69F is too bugged.

or

B)   RELTRY69F is uploaded and ready to listen.

 

John

 

 

 

[John Dyson]

Good news...

V20B-RELTRY69F is uploaded and ready...   The actual release and/or the demo is expected to contain the decoder binary & source for Windows & Linux on Wed 22Nov.  This version should be very close to the next demo or release.   Whether the next is demo or release depends primarily on the lack of problems in this version.  I will make announcements to the private/PM/email reviewers/testers/contributors in a few hours -- I just cannot do anything more right now.   Those with strong/specific interest in the project, let me know and I am willing to privately decode some tracks or once-in-a-while will privately decode an album.

 

Pointer to the entire public repository is provided just in case you are very interested, and want to watch incremental steps in progress.   Currently, we are primarily interested in V20B-RELTRY69F.   Earlier versions are best ignored, unless doing comparisons for regressions (decoder getting worse instead of better.)

 

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

(The full public repo link is not likely to disappear for many months, perhaps multiple years..)

 

Pointer to V20B-RELTRY69F...   This pointer will tend to disappear when V20B-RELTRY69F is no longer important.   Right now, this pointer supports slightly easier access to the RELTRY69F  demos:  https://www.dropbox.com/scl/fo/ssakc9gifjad96e5dmy3p/h?rlkey=gzfltpsuzmv07vxeyzue0zssf&dl=0

 

Contents/sub directories of RELTRY69F:

fscmp10-V20B-V20B-RELTRY69F:   contains 10 second A/B/A/B comparisons...

( often not very useful, beginnings of tracks are often uninteresting)

 

fscmp35-V20B-V20B-RELTRY69F:  contains 35 second A/B/A/B comparisons...

( more likely to give a more accurate sense of what the decoding can do)

 

flacsnippet-V20B-V20B-RELTRY69F+5-0:  contains full snippets

( I tend to prefer these full snippets because they give a more complete sense of the sound of the decoder.)

 

 

This version SEEMS to 'decode' or mostly 'expand' very cleanly.   I have some suspicion that the dynamics processing could be a little stronger to be more correct, but the dynamics expansion on this version is effective.   CRITICISM IS WELCOME...   Very often, improvement comes as the result of criticism.   If the decoder is perfect for you, then mention of that being true is also helpful, but please try to be as aggressively picky as you can -- PLEASE.   All I ask is to be kind.   Kindness can definitely include helpful criticism!!!   PLEASE TELL ME ABOUT THE LF/HF BALANCE.   There is no 'hard' setting, but a series of 'ratchets' that can be set.   I don't know which is correct because of the various loss of LF and HF hearing.   The settings are about 1-3dB apart, but I still cannot judge (loss of hearing on this project has been so frustrating...   Cannot even hear the full benefit of the results!!!)

 

The dynamics expansion is very different than what one might expect using an RMS expander because the FA decoder goes deeper into the waveform.   An RMS or peak detector might effective have attack times of 1-4msec for natural sounding results.   The FA decoder has an attack time of almost 'infinitely fast', a big part    is  waveform based, with a lower level componet with the typical 1-4msec attack, 40-160msec release.

 

With this version, actually decoding, I have had to modify my expectations WRT noise reduction.   Some recordings have lots of hiss on the actual source tape, which means that the decoder reproduces that hiss without noise reduction.   When the hiss happens after FA encoding, then the decoder noise/hiss reduction is pretty effective.

 

A release or demo (depending) is planned for Wed 22 Nov, with bugfixes relative to this (RELTRY69F) demo release, if any.   Even the slightest bug or weakness will be addressed, possibly corrected.   The 22 Nov version will also be in the public repository, but with the new version ID.   The actual release if not on 22Nov is expected to be 1wk later.  Assuming no 'tragedies' of any sort, there will also be a binary/source, runnable on Windows or Linux, on Wed 22Nov also.   All times herein are USA EST (or is it EDT?).

 

Sincerely,

John

 

[John Dyson]

I will let you know before the end of the day, if RELTRY69F has missed the mark or not.

One or two of the reviewers will likely take a 'quick listen' and might be able to tell me what they think about the sound quality.

 

ADD-ON:   I found that the signal was being very slightly clipped, and might have been a big part of my worry about quality.   I didn't realize that the clipping was happening.   Still, I might, just might be hearing a MINOR problem  

 

I noticed either the highs being slightly enhanced (bad thing) or perhaps it is my imagination.  I'd rather that no casual users would bother with a broken release of any kind.   I just do not know because of my hearing problems.   So, to avoid wasting any casual user's time, I wish to forewarn that this might have a slight problem with the modulation of the very high frequencies.   It creates a strange feeling when listening, but need some comments whether or not the highs seem correct.

 

The change might seem trivial, but comprises the correct EQ sequence of about 10 LF EQs so that the highs are modulated correctly.   NOTHING IS EASY ABOUT THE CHANGE (however simple it might seem), but the decoder works, and seems generally okay on POP/ROCK.   If the decoder really does need a correction, the change to most POP/ROCK won't be extreme at all.

 

This possible problem is regrettable -- my hearing returned about1Hr after the uploads were complete -- and in general, the decoder is doing REALLY good.   However, I might be hearing a minor flaw, and am probably correct.   I am starting on it in about 1-2Hrs, if needed, should take a few hours to correct at most.

 

John

 

[John Dyson]

My caution might have been excessive.   The stereo image is pretty good, but perhaps a slight upward tilt in the HF -- not terribly intrusive though.

 

Unless there is feedback otherwise, V20B-RELTRY69F does appear to meet my original expectations for this release.   Of course, criticism is welcome because I still might have missed more bugs.

 

Enjoy -- because it does seem to work.   Cautions:

1)  Might need a bit more dynamics processing by the descrambler.

2)  The timing/LF EQ settings might have a small mistake/error..

 

It would take a few days of continual usage to zero-in on the corrections...

 

We ALMOST have a real FA decoder.

 

John

 

[John Dyson]

Status:

The reviewers and myself are in the process of soon 'declaring victory', or at least a reasonable first version.   The equivocation come because we need to accumulate more feedback from reviewers and users AND, most importantly AND, we need a windows version of the decoder.  The only way that true victory can be declared is if there is a decoder available to use in both source and binary forms.

 

The plan is to upload a copy of the Linux & Windows decoders, plus the demos on late Wednesday (middle/late evening my time, USA EST/EDT.)

At that point, the versioning identification will be modified and reset as a 'release V1' type thing, while also keeping the development version ID.   The plan is to keep the development IDs while releases keep a parallel scheme.   Also, the decoder will be placed under Git version control.   It will be a relief to back up literally 1000's or 10000's of versions/tests/etc.   I had NO idea that the decoder was going to be more than 10 iterations, otherwise would have used Git (or other version control) from the start > 5yrs ago.

 

Minor, very minor changes are possible in sound character, but almost every change that I make to improve stereo image/etc results in 'flattening'.   I might find a slight change before Wednesday, but is unlikely to improve very much.  Command line improvements WILL be made, and at least a release notes/short usage guide will also be produced (for the first time in several years.)   The bug that I thought uncovered immediately after uploading V20B-RELTRY69F was my screw-up while using the decoder.   After using the decoder more correctly, the resulting sound was essentially correct, as originally expected.

 

Sincerely,

John

 

[John Dyson]

I have been thinking about an effective plan -- since the decoder must stabilize before the Windows decoder is ported, which is fairly simple, I'll produce the 'final' version tomorrow (Sun, perhaps Mon) night.  This will include some very minor improvements along with the somewhat more work to update new command line structure.   There shouldn't be anything to delay it. This will give time to produce a stabilized Windows command line version also.

 

There was a minor complaint on Aja/Aja, which is very trivial to fix.   Otherwise, there haven't been too many important regressions.   The Aja thing is going to be slightly changed for 'political' reasons.   I am pretty sure about ABBA, Carpenters, Carly Simon, Simon & Garfunkel, some London orchestral recordings, ONJ, some Gershwin stuff are all okay (maybe not perfect for the fans of each group, but probably very close to correct.)

 

Honestly, I am pretty amazed so far.

Of course, as more reviewers/correspondent/friends give feedback, there MIGHT be more criticism coming.   However, the code design is now totally solid -- just changes to very minor things are possible.

 

What an intense 5+yrs.   Of course, more to come -- but not quite as deep into the technology.

John

 

[John Dyson]

More good news:  just verified the command line, make the very minor Aja correction (which helps some other things to a small degree.)

 

There is planned a V20B-RELTRY70A tomorrow evening, then I'll start working on the Windows binary.

As soon as the Windows binary is proven, we won't need to technically rerun the 70A demos, but if they are good enough, then there will be a RELEASE1,V20B-RELEASE.   Given the variations in the release ID, the demos need to be rerun (internally, the release information resides in the .wav files.)   Normally, RELEASE1 will be the ID.

 

This is probably more complicated than it needs to be, but I think that the algorithmically complete binary is now usable.

More often than not, there are improvements in the resulting sound -- probably 98-99% of the time.

 

John

 

[John Dyson]

One of the reviewers caught indeed a serious bug.   It will be fixed in the 'final' release today.   The release today will be V20B-RELEASE1, which will hopefully morph into RELEASE1(V20B-RELEASE1).    I know, kind of contorted, but I want to keep the old release information.   Maybe I can hide the V20B-RELEASE1 all together, and simply depend on the archives for before the actual RELEASE1?   I am horrid at naming things.

 

Oh, BTW -- the bug.   Beyond stupid...   I filtered out the 'pilot'.    Adding it back in, the result/improvement is subtle, but makes a learned subjective difference.

Even then, forewarning everyone -- the difference between original and decoded is and always will be subtle on many recordings.   On some recordings, e.g. Anne Murrays' recordings, the difference will be very small.   On others, the difference is greater.   On some recordings, the sound will be disappointing, because part of the character comes from the FA processing.

 

I am hoping that the result, esp after adding back in the pilot information (again, subtle), will result in a slightly more natural sound.

 

The whole idea of FA back when started is that it should not be intrusive, but cause just enough distortion that it isn't the same as the original intellectual property.   Kind of like an ancient MQA type thingie.   The difference between MQA and not-MQA before decoding is small, but existent.    That would be similar with FA, but FA is a bigger difference.   (Difference between eccentricly dithered 14bits and 16bits isn't all that great, but enough to be disturbing to many people.   The loss of origingality also is profoundly disturbing.)

 

The V20B-RELEASE1 demos decoding is in process right now.   The decoder also has the desired command line for the first release.

 

John

 

[John Dyson]

The person who caught the problem, ending up being 'missing pilot', has helped to fix a pronounced amount of garble in the output.

Major problem avoided!!!

 

When listening, the result is now REALLY REALLY GOOD, and the planned release.

 

John

 

[John Dyson]

Made some last minute mistakes in previous release -- basically disabled most of it.

The previous demo was JUST WRONG, essentially nulled out the decoder...

 

I allowed too many interruptions, allowing my lack of discipline and forgetfulness allow for incomplete changes.

I have been promised 2 days of no interruptions, allowing me to finish things with fewer mistakes.

 

I am slowly re-enabling the sections that got removed by ham-handedness.

Full beauty being re-enabled, and I plan to make the upcoming demo version the release version also.

 

Taking my time on this, hoping for Wednesday, and it is expected to be a release (without the decoder binary yet -- Linux will be uploaded, but will not name it officially the release until the Windows binary is available.)

 

John

 

[John Dyson]

The final release for technology seems to best be more carefully tested.

The goal, relatively easily met, will be 29Nov.   The code is working right now, but lots more review and testing, first by me, needs to be carefully done.

The previous release was working well, but only doing the DA layer processing.   The descrambler was basically nulled out, working only in certain limited cases.

 

In the next week or so, I might have some private conversations about specific tests, but there have been too many attempts at launch, even worse than the 'Starship.'   Frustratingly, for a single developer, the decoder is about as complex as the 'Starship' might be for 10,000.   Time to reset -- the decoder is basically amazing, but unfortuately -- 'basically' isn't good enough, and working but subsequently broken is also not good enough.

 

A layer of 'integration testing' would be so helpful, but my development keeps diverging.

We have a very solid DA layering, can be proven by low signal level performance with consistent HF/LF balance.   The DA layers haven't been touched in months (except for layer thresholds).   For recent testing, the discriminators got disabled by several testing #ifdefs.   Lots of internal testing has been done, but enabling and disabling the testing code was done haphazardly.   A new testing/debugging structure will be added so that stuff isn't mistakenly disabled or special testing code isn't enabled.   A more organized command line testing capability will also be added.   There is already a testing command for enabling/disabling sections of code, but I had even been explicitly confused by when the enabling and disabling has been happening.

 

So, YES, the descrambler was disabled in the previous release.   It will be fixed, but with fastidious care.

My random deafness will also be better considered.

 

John

 

[John Dyson]

Found the problem, it was very serious and disabling -- it was a 'noble' attempt at speeding up the descrambler, which does take a lot of time in one thread.   Basically, it limited the speed of the decoder even on the fastest machines.

 

Some bad speedup-changes in the descrambler were made when my hearing was especially bad, which made A/B comparisons difficult, if not simply incorrect.

So much for blaiming my hearing, but also the problem came froma bad case of expectation bias.   A/B comparisons are easily thwarted by expectation bias, especially when needing to do a massive number of comparisons, then  becoming lazy on how the comparisons are done...

 

The above is a 'mea culpa', but the good news:  the fully functioning descrambler was found in the archives, but other things were added from other aspects of the descrambler that had subsequenty been learned.   A technically reassuring, the discriminators no longer need a Q=sqrt(2), but instead work perfectly with Bessel (actually semi-Bessel) at Q=0.5771 or theoretically might be better with 2nd order Butterworth Q=0.7071.   Haven't decided on the correct choice of the two yet.   The lower Q means that the descrambler works more easily -- not needing to be forced with the higher Q.

 

One of the test subjects, very difficult, has been the self titled Aja on the Aja album.   The vocal tends to smear/become distorted at certain points in the recording.   The new descrambler mitigates this to some degree, but the decoder quality can be turned up and the detail might be fully revealed.

 

The sad and frustrating thing is that the descrambler is slower again (but functional).   Any new 'speedups' will be done more carefully.  Everything possible has been done given the current math -- the large number of IIR filters have been done efficiently.  Unfortunately, like most of the other parts of the decoder, the math MUST be done in double-precision.  Perhaps if normal floating point had 4 more bits, then double precision might not have been necessary.

 

Bad bad letdown...   There is a holiday coming up, and won't be able to promise a correction now for about 1wk.   If there are any very much improved results (already achieved), but with the highest confidence (still need to build confidence), then a demo will be uploaded before +1wk.

 

It appears that through the last 7-9yrs, my technical & hearing ability has been impacted to some degree.   Back in about 2009-2010, I was still doing pretty well, but I had noticed some troubles right after that, and an apparent decline in hearing and mental acuity.   The project isn't impossible for me, but it is coming time that the difficult parts of the program need to be completed.   This is very challenging stuff for anyone, where most of my immediate co-workers, colleagues no longer do this difficult kind of work.   Hopefully, I'll be able to improve the quality of my work on this project by being less lax, and working with greater focus on *quality*.

 

There isn't a lot more technical innovation needed -- completing the decoder should mostly be left-over 'gruntwork', but mistakes on the gruntwork are just as damaging as mistakes on the more challenging parts.   Mistakes in 'gruntwork' caused this delay.

 

John

 

[John Dyson]

Sorry for the previous screw-up.  The intent was true, just that I screwed up.

The descrambler has been rebuilt and have integrated an older discriminator design that had previously been functional.

The newly re-constituted descrambler is fully functional, verified several times, also by another local person.

 

The metaprogramming has also been optimized to take advantage of some new settings that were developed over the last few months.

 

There were several reasons for attempting an improved design, but ended up being botched.

 

* MISTAKE: Low level change in the base descrambler attempting to soften the sound of the processing.

* MISTAKE: Misguided simplification, speedup...

* MISTAKE: Other metaprogramming errors when down the 'speedup' rabbit hole.

 

Function has been restored, but without a speedup.   The 'excess intensity' has also been addressed as part of the metaprogramming, not requiring changes to the low level parts of the descrambler.

 

Retrying the descrambler speed 'optimization' changes at this point are too risky.   There will be no changes to 'speed up' the descrambler.   The total decrease in CPU was actually pretty small, but the 'speedup' removed a bottleneck.   The 'speedup' is more challenging than I had originally thought.   Not going to bother for now.

 

As of right now, there is a frozen high level design, changes only for bugfixes and changing the metaprogramming for attempting correct dynamics.

 

I will be asking for one-on-one private reviews of recordings, only spot-checks of one or two tracks until it is time to start creating the demos.  The spot-checks will be for double checking functionality, just to make sure that some kind of expectation bias hadn't crept in.

 

By a misguided 'speedup', misguided solution for intense sound, and further mistakes down the associated rabbit hole, the previous release ended up being a non-functioning descrambler, only doing raw EQ instead of the dynamics also.

 

There will be a status message on approx Tuesday, before then, some one on one double-checking with 2 or 3 of the active AS reviewers.

(There is no intent on leaving any of the reviewers out of the loop, just that I want to bother as few people as possible, until there is something to offer.)

 

John

 

 

 

[John Dyson]

The 'RELTRY69F' wasn't quite as 'disabled' as I had originally thought, also my too-aggressive response was based on one, very kind and concerned feedback message.

 

The descrambler on the RELTRY69F was not working optimally, and functioning too conservatively -- probably because the discriminators mathematically tripped over each other, causing each to partially cancel it's neighbors out.

 

A non-functioning descrambler doesn't usually sound 'bad', just doesn't function as strongly as it should.   So, bad functioning usually means 'weak' functioning, not 'more distorted'.

 

More focus is now on the correct set of tradeoffs to be 'more correct', or 'more chances of being correct'.

The A/B comparison process appears to drift since there are poor or inappropriate references.   I am trying to avoid too much drift, trying to refer back to the original 'never-FA' recordings moreoften then just doing relative A/B comparisons on different decoder versions.

 

I know that these claims have been made before, but suffice to say that the RELTRY69F wasn't architecturally broken much at all  (other than the discriminators were weak/cancelled each other).   Also, some recordings do appear to be improved on RELTRY69F, but the processing didn't go far enough.   *Many recordings will not show much difference when the descramblers don't work correctly.*

 

When the descrambler knife-edged settings are correct, the program has been producing more noticeably improved results..

(Still lamenting the lack of objective comparison methods, but are getting closer to the goal - JUST NOT AS CLOSE on RELTRY69F.)

 

To the several that said 'go with RELTRY69F' or something equivalent...   I so much appreciate the encouragement, but someone DID find a problem, a serious problem, and is being corrected, IT IS BEING CORRECTED VERY CAREFULLY and METHODICALLY.

 

Instead of focusing on the entire decoder, being mostly correct, the focus is on the section that needs improvement.   There is less 'defocusing' on other issues, because the other issues have been resolved.

 

John

 

[John Dyson]

Notes about V20C, DEMO (DEMOFIN)release.

*  The V20A-RELTRY69F release was *just broken*, and the delay was more than necessary.   I have already fallen on my face multiple times, and didn't want this final series of releases to end up being broken.

 

The processing goes MUCH deeper in V20C, in a sense might be thought of as a 10:1 expander instead of 1.2:1, but not exactly.   Also, there is a hidden, probably unintentional  'pilot' that is used for guiding the decoder.   The basic 'pilot' doesn't contain a huge amount of information, but enough to help quite a bit.   There is the possibility that more 'pilot' information might be available in 'quadrature'.   Will investigate more about the pilot for the future.

 

The public 'stuff', is at the following location.   The usual constituents of '35 second A/B/A/B, 10 second A/B/A/B and full snippets' are in subdirectories...   The non-public stuff is also in the usual locations...

 

V20C-DEMOFIN public tree:

https://www.dropbox.com/scl/fo/p7dphek26jnxmykioy4rm/h?rlkey=zwsbmqk4q60vucc7l6dib9p4i&dl=0

 

Sorry, no decoder binary or source.   If I have time before tomorrow, I'll upload and announce a Linux source/binary, but my Windows capabilities are still limited -- ALL of my time being spent on correcting the total botch of a V20A-RELTRY69F release.   It was a *good* thing to get the criticism from one of the reviewers -- HE CAUGHT THE 'RELTRY69' BUG, a rather major one.

 

Because of logistics reasons, after tomorrow or day after, there cannot be any updates for 1.5-2wks, and can only be limited discussion.   This necessary 'disappearing act' is probably a good thing and might give time to try the rather major improvements in the decoder.  The decoder is not perfect, and cannot make a 'silk purse out of a sow's ear', but can improve the sound of well made recordings.   * Once I am available again, a few lingering matters will be revisited, and the full focus will be on the release.

 

The new 'untieing' uses a 'pilot' signal, where the details are best not pubically disclosed until I am sure about what is going on.   If the 'pilot' is removed, then an FA signal cannot be fully decoded.  ONLY V20C and later can fully utilize the pilot.  The pilot signal is fragile.   It appears that some Youtube material has had the pilot naturally removed.   Some natural encoding operations, e.g. mp3 type encoding, will unfortunately remove the 'pilot' very effectively.  Also, vinyl recordings will also naturally remove the pilot (unless VERY carefully made.)   The decoder can still process/improve the pilotless recordings, just not as well.

 

*  The 'pilot' is probably an unintentional/natural artifact of part of the FA encoding mechanism, which fortunately gives very good hints about the recording.

 

* There is LITTLE OR NOT HISS REDUCTION ON SOME OLDER RECORDINGS.   Certain other recordings are significantly noise reduced.

* The 'remastered' (normal, track 1) version of ABBA 'SOS' might have a problem -- an unnatural amount of compression in the commodity version (track 1) instead of the more natural (track 4) version.
* There is sometimes a 'ringing' of the HF 'details', which definitely reminds of an excess LF subharmonic being untied.
* There might still be some 'Gibbs' problems, but most obvious cases seem to be corrected.

 

John

 

 

 

 

 

 

 

[John Dyson]

On demo release, V20C-DEMOFIN, for audio purists, below is a set of response curves for the decoder.   '0dB' is actually about -0.25dB, so when you see all of the '-0.xx' dBs, those are actually based upon an average of '-0.25dB' or so.   THESE RESPONSE CURVES ARE STATIC.   There is no practical way to measure the frequency response, even from millisecond to millisecond, the response is 'just weird'.

 

* IMPORTANT NOTE ABOUT THE V20C-DEMOFIN RELEASE, it is the final for basic processing, but there is the serious need for a bit of cleanup.*

 

There is a bit of a flaw below around 300Hz, where the response goes up by about 0.25 to 0.5dB.   These numbers just came out of the design, no huge tricks to get a flat response are being done....     I decided that 'flattening' the response isn't really needed, because the decoder mucks with so many aspects of the signal that a few 0.1's of a dB shouldn't be very important.   (The dynamic/instantaneous expansion could be thought of as approx 20:1 in dB terms, but doesn't manifest the same as normal expanders might.)

 

LEVELS 20Hz to 20000Hz
dB raw: -23.56 dB dec: -23.55 dB gain: 0.01
LEVELS 1000Hz to 3000Hz
dB raw: -37.81 dB dec: -38.17 dB gain: -0.36
LEVELS 3000Hz to 20000Hz
dB raw: -40.21 dB dec: -40.61 dB gain: -0.4
LEVELS 2900Hz to 3000Hz
dB raw: -52.25 dB dec: -52.75 dB gain: -0.5
LEVELS 2800Hz to 2900Hz
dB raw: -52.01 dB dec: -52.49 dB gain: -0.48
LEVELS 2700Hz to 2800Hz
dB raw: -51.76 dB dec: -52.21 dB gain: -0.45
LEVELS 2600Hz to 2700Hz
dB raw: -51.50 dB dec: -51.91 dB gain: -0.41
LEVELS 2500Hz to 2600Hz
dB raw: -51.21 dB dec: -51.60 dB gain: -0.39
LEVELS 2400Hz to 2500Hz
dB raw: -50.91 dB dec: -51.28 dB gain: -0.37
LEVELS 2300Hz to 2400Hz
dB raw: -50.60 dB dec: -50.94 dB gain: -0.34
LEVELS 2200Hz to 2300Hz
dB raw: -50.28 dB dec: -50.60 dB gain: -0.32
LEVELS 2100Hz to 2200Hz
dB raw: -49.95 dB dec: -50.26 dB gain: -0.31
LEVELS 2000Hz to 2100Hz
dB raw: -49.62 dB dec: -49.91 dB gain: -0.29
LEVELS 1900Hz to 2000Hz
dB raw: -49.30 dB dec: -49.58 dB gain: -0.28
LEVELS 1800Hz to 1900Hz
dB raw: -48.98 dB dec: -49.26 dB gain: -0.28
LEVELS 1700Hz to 1800Hz
dB raw: -48.68 dB dec: -48.96 dB gain: -0.28
LEVELS 1600Hz to 1700Hz
dB raw: -48.40 dB dec: -48.69 dB gain: -0.29
LEVELS 1500Hz to 1600Hz
dB raw: -48.14 dB dec: -48.46 dB gain: -0.32
LEVELS 1400Hz to 1500Hz
dB raw: -47.91 dB dec: -48.25 dB gain: -0.34
LEVELS 1300Hz to 1400Hz
dB raw: -47.66 dB dec: -48.04 dB gain: -0.38
LEVELS 1200Hz to 1300Hz
dB raw: -47.35 dB dec: -47.78 dB gain: -0.43
LEVELS 1100Hz to 1200Hz
dB raw: -46.89 dB dec: -47.38 dB gain: -0.49
LEVELS 1000Hz to 1100Hz
dB raw: -46.24 dB dec: -46.78 dB gain: -0.54
LEVELS 900Hz to 1000Hz
dB raw: -45.39 dB dec: -45.96 dB gain: -0.57
LEVELS 800Hz to 900Hz
dB raw: -44.44 dB dec: -45.02 dB gain: -0.58
LEVELS 700Hz to 800Hz
dB raw: -43.52 dB dec: -44.07 dB gain: -0.55
LEVELS 600Hz to 700Hz
dB raw: -42.68 dB dec: -43.15 dB gain: -0.47
LEVELS 500Hz to 600Hz
dB raw: -41.65 dB dec: -41.97 dB gain: -0.32
LEVELS 400Hz to 500Hz
dB raw: -39.98 dB dec: -40.12 dB gain: -0.14
LEVELS 300Hz to 400Hz
dB raw: -38.00 dB dec: -37.97 dB gain: 0.03
LEVELS 200Hz to 300Hz
dB raw: -35.83 dB dec: -35.63 dB gain: 0.2
LEVELS 150Hz to 200Hz
dB raw: -36.66 dB dec: -36.40 dB gain: 0.26
LEVELS 100Hz to 150Hz
dB raw: -35.89 dB dec: -35.72 dB gain: 0.17
LEVELS 50Hz to 100Hz
dB raw: -36.02 dB dec: -35.96 dB gain: 0.06
LEVELS 40Hz to 80Hz
dB raw: -38.20 dB dec: -38.08 dB gain: 0.12
LEVELS 20Hz to 50Hz
dB raw: -46.50 dB dec: -46.27 dB gain: 0.23
LEVELS 20Hz to 30Hz
dB raw: -61.17 dB dec: -60.98 dB gain: 0.19
LEVELS 10Hz to 30Hz
dB raw: -60.82 dB dec: -60.70 dB gain: 0.12

LEVELS 20Hz to 20000Hz
dB raw: -23.56 dB dec: -23.55 dB diff: 0.01
LEVELS 3000Hz to 20000Hz
dB raw: -40.21 dB dec: -40.61 dB diff: -0.4

LEVELS 1000Hz to 3000Hz
dB raw: -37.81 dB dec: -38.17 dB diff: -0.36

LEVELS 2800Hz to 2900Hz
dB raw: -52.01 dB dec: -52.49 dB diff: -0.48
LEVELS 2900Hz to 3000Hz
dB raw: -52.25 dB dec: -52.75 dB diff: -0.5
LEVELS 3000Hz to 4000Hz
dB raw: -49.18 dB dec: -49.77 dB diff: -0.59
LEVELS 4000Hz to 5000Hz
dB raw: -50.66 dB dec: -51.23 dB diff: -0.57
LEVELS 5000Hz to 6000Hz
dB raw: -51.13 dB dec: -51.55 dB diff: -0.42
LEVELS 6000Hz to 7000Hz
dB raw: -51.56 dB dec: -51.89 dB diff: -0.33
LEVELS 7000Hz to 8000Hz
dB raw: -52.39 dB dec: -52.68 dB diff: -0.29
LEVELS 8000Hz to 9000Hz
dB raw: -53.63 dB dec: -53.90 dB diff: -0.27
LEVELS 9000Hz to 10000Hz
dB raw: -55.14 dB dec: -55.40 dB diff: -0.26
LEVELS 10000Hz to 11000Hz
dB raw: -56.80 dB dec: -57.06 dB diff: -0.26
LEVELS 11000Hz to 12000Hz
dB raw: -58.52 dB dec: -58.78 dB diff: -0.26
LEVELS 12000Hz to 13000Hz
dB raw: -60.24 dB dec: -60.50 dB diff: -0.26
LEVELS 13000Hz to 14000Hz
dB raw: -61.94 dB dec: -62.19 dB diff: -0.25
LEVELS 14000Hz to 15000Hz
dB raw: -63.59 dB dec: -63.85 dB diff: -0.26
LEVELS 15000Hz to 16000Hz
dB raw: -65.22 dB dec: -65.49 dB diff: -0.27
LEVELS 16000Hz to 17000Hz
dB raw: -66.82 dB dec: -67.10 dB diff: -0.28
LEVELS 17000Hz to 18000Hz
dB raw: -68.41 dB dec: -68.72 dB diff: -0.31
LEVELS 18000Hz to 19000Hz
dB raw: -70.01 dB dec: -70.34 dB diff: -0.33
LEVELS 19000Hz to 20000Hz
dB raw: -71.64 dB dec: -71.97 dB diff: -0.33
LEVELS 20000Hz to 21000Hz
dB raw: -73.31 dB dec: -73.61 dB diff: -0.3
LEVELS 21000Hz to 22000Hz
dB raw: -75.04 dB dec: -75.25 dB diff: -0.21
 

 

LEVELS 20Hz to 20000Hz
dB raw: -23.56 dB dec: -23.55 dB diff: 0.01
LEVELS 575Hz to 600Hz
dB raw: -44.15 dB dec: -44.54 dB diff: -0.39
LEVELS 550Hz to 575Hz
dB raw: -43.96 dB dec: -44.30 dB diff: -0.34
LEVELS 525Hz to 550Hz
dB raw: -43.73 dB dec: -44.03 dB diff: -0.3
LEVELS 500Hz to 525Hz
dB raw: -43.45 dB dec: -43.71 dB diff: -0.26
LEVELS 475Hz to 500Hz
dB raw: -43.14 dB dec: -43.35 dB diff: -0.21
LEVELS 450Hz to 475Hz
dB raw: -42.79 dB dec: -42.96 dB diff: -0.17
LEVELS 425Hz to 450Hz
dB raw: -42.42 dB dec: -42.55 dB diff: -0.13
LEVELS 400Hz to 425Hz
dB raw: -42.05 dB dec: -42.13 dB diff: -0.08
LEVELS 375Hz to 400Hz
dB raw: -41.69 dB dec: -41.73 dB diff: -0.04
LEVELS 350Hz to 375Hz
dB raw: -41.37 dB dec: -41.37 dB diff: 0
LEVELS 325Hz to 350Hz
dB raw: -41.09 dB dec: -41.05 dB diff: 0.04
LEVELS 300Hz to 325Hz
dB raw: -40.84 dB dec: -40.75 dB diff: 0.09
LEVELS 275Hz to 300Hz
dB raw: -40.60 dB dec: -40.46 dB diff: 0.14
LEVELS 250Hz to 275Hz
dB raw: -40.31 dB dec: -40.14 dB diff: 0.17
LEVELS 225Hz to 250Hz
dB raw: -39.95 dB dec: -39.73 dB diff: 0.22
LEVELS 200Hz to 225Hz
dB raw: -39.49 dB dec: -39.24 dB diff: 0.25
LEVELS 175Hz to 200Hz
dB raw: -38.97 dB dec: -38.70 dB diff: 0.27
LEVELS 150Hz to 175Hz
dB raw: -38.53 dB dec: -38.27 dB diff: 0.26
LEVELS 125Hz to 150Hz
dB raw: -38.40 dB dec: -38.19 dB diff: 0.21
LEVELS 100Hz to 125Hz
dB raw: -38.74 dB dec: -38.61 dB diff: 0.13
LEVELS 75Hz to 100Hz
dB raw: -39.19 dB dec: -39.16 dB diff: 0.03
LEVELS 50Hz to 75Hz
dB raw: -40.32 dB dec: -40.21 dB diff: 0.11
LEVELS 25Hz to 50Hz
dB raw: -46.71 dB dec: -46.48 dB diff: 0.23

 

 

[John Dyson]

One more thing, I didn't elucidate an important fact about DEMOFIN...   It has a bit of 'fuzz' in the sound, very much corrected by improving the handling of the pilot.

 

Sorry about the quality problem, but when reviewing, please try to take the slight fuzz into consideration, and it IS fixed in the current test code, just couldn't make it available in time given the current constraints...

 

The release will NOT have noticeable 'fuzz'.

 

John

 

[John Dyson]

There might be enough time to create a release with all of the 'fixins' to the current release.

Running tests right now, and had been in the midst of producing some albums for some friends.  It seems best to do one more step of cleanup and redo the demos.

 

I'd hate to leave the bugfixes sitting on the development machine instead of available for review.   There is still not time to do a Windows version of the decoder, but if there is enough time, I'll make a source and Linux package before I leave.

 

The bugs aren't really 'algorithmic', but more related to mitigating some Gibbs and Nyquist problems.   The decoder is technically FAR FAR FAR from linear, just like any gain control device that changes the gain alot.   Even though the decoder sounds pretty much 'linear', especially nowadays, it does gain control which is no.

 

Doing the kinds of operations in the decoder, there will be modulation products and harmonics.   It takes some serious trickery to do the decoder at 88.2k or 96kHz sample rate internally.

 

I'll do my best to make the decoder available late Friday night or Saturday morning.   I have a 'candidate' version right now, but requires some testing.  It is close to being finalized for the demo, otherwise I wouldn't mention it.

 

John

 

[John Dyson]

Approx schedule to squeeze in an update, there is about 1-2days left...   After that, it will be 1.5wks or so before any new corrections.

(Sorry for rambling, but basically I am pushing my time limit to squeeze out the best possible demo release before my unavailability.)

 

The previous demo came out pretty well, but I found a *minor* problem near the end of producting the demos.   I set an artificial limit of about 1-2days before the time of unavailability, but have decided to utilize that time to integrate the quality improvements.

 

It has been a bit troublesome because the HF in my hearing has gone blank again.   Totally accurate HF hearing isn't needed for part of the descrambler corrections, because IF the descrambler is set incorrectly, there is usually a 'grinding' in the sound.   Most FA recordings have this 'grinding' sound, sometimes hidden by additional dynamics compression.  Even then, it is much less confusing if HF hearing is available for easier A/B comparisons.

 

When the dynamics compression is removed incorrectly, the 'grinding' will appear.   Even though there has been improvements, the game of 'whack a mole' has started again, and need at least a few more hours of good hearing.   A new release could probably have already been done, but EVERY noticeable mistake is being chased down.

 

As there are incremental improvements, it has been easier to detect smaller and smaller errors.   The current test code is better than the most recent test/review demo, but I want to make the release during the 1.5wk hiatus to be as good as possible.

 

The hard time limit is approx 36Hrs from now.   I'll do everything that I can do to add in the corrections, and make sure that 'grinding' hasn't become noticeable.   Once a 'perfect' decoder is found, there is about an 8 Hr delay to produce the demos and ABBA recordings.   Right now, the 99 demos are highest priority.

 

John

 

 

[John Dyson]

The V20CR105 demos are on the way.  (The Carpenters demos are done by a later development decoder)...

 

I am a little bit worried about the HF...   The HF might seem to be 'overly clean' sounding, which can be caused by a few reaons, including the intended handling of the modulation of the recording by utilizing the 'pilot', or could even be a missing lower midrange.   I just don't know -- in fact, the perceived response might just be as flat as the static measurements show.

 

The uploads are partially complete, and still progressing...

I have promised to produce a Windows PC version of the decoder, but unable to because of very tight time limitations.   The upcoming release when I get back will include the Windows binary.   In a few hours, I'll might have time to upload the Linux binary & source, but there is some prep work needed.

 

Here is the public rep, which will be filling up soon.   ABBA snippets, the 99 demos and Carpenters snippets are coming.

 

Web location for public demos (snippets and A/B/A/B comparisons):

https://www.dropbox.com/scl/fo/zmeiisyml9r6zdi3rvdtk/h?rlkey=4sfe50nw0yyxiysnvfckm42ht&dl=0

 

More discussion will be coming later on -- but a lot of distortion from FA encoding has been removed.   Feedback on the response balance would be VERY helpful.   IN certain places, there is no 'absolutely correct' response, because of several places where there are 'original designers choices'.

Expect this stuff to be stable for 1 to 1.5wks after today.

 

John

 

 

[John Dyson]

Found another possible problem -- public or private feedback welcome...

There might be a phase problem that makes the midrange seem to have a dip (decrease) in dynamics processing.

 

An idea about how the midrange sound could be very helpful -- I am working the problem from a more technical standpoint, and the decoder just might be correct anyway.   It sure seemed correct with the current configuration for a few days -- certainly the decoder cannot drift 🤣.   Given the sensitivity of some of the settings, I could *almost* believe that drift is possible.

 

John

 

[John Dyson]

Gonna push the time limit to see if one more improvement can be added by later today (zero time left over), I am super hopeful about this code series being *it*.