Jump to content
IGNORED

'FeralA' decoder -- free-to-use


Recommended Posts

I have been experimenting away for the past two weeks or so and used 2.1.1F on CD rips from about 7 groups/artists. In all cases, I realized improvements to varying degrees. John's snippets contain variety, but are missing racous/rowdier music. Among my selections were Toots and the Maytals 'True Love', and Albert Collins and the Icebreakers 'Live in Japan', for example. 

 

My usage scenario is probably somewhat different than some, perhaps most others. I'm converting all the songs from an album using a script using the da-win process since my cpu cannot run da-avx. Each song takes perhaps 1.3-1.4 times the playback time to convert. Rather than the simplest default command line my current call is:

 

da-win --input=$outfile --overwrite --output=$newout --info=1 --fa=M --pe90=1,0.75,1.17 --pe90=1,0.75,1.17 --pe90=1,0.75,1.17 --outgain=+6

 

This gives a result that matches the input fairly well in term of dynamics and bass (without the bass bloat). In some cases I have needed to reduce the --outgain to +3.  I do think some of the reports of flatness may have resulted from the quietet output inviting Messrs. Fletcher and Munson to the party when the output is not increased to resemble the level of input played back at the same gain on the same system. And, of course, the congestion that the decoder is removing makes  the original sound louder anyway.

 

To close, I have just finished listening to 'The Lamb Lies Down on Broadwy' by Genisis. While I have always appreciated this, this was the first time I have been able to listen to and enjoy the whole album at one sitting because of the now removed congestion.

 

Thanks, John. I look forward to using each fixed and improved version without fearing, as I have in that past, that I would not necessarily be going back and reconverting all the files repeatedly as the new versions zigged and zagged. 

 

Skip

Link to comment

New release -- V2.1.2L

 

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

 

(Will also reply to other very interesting postings, and try to help with troubles.)

First version to have anti-MD for the MF band.

 

Better HF EQ, orig used 3 9k->21k low pass shelving filters instead of now 2 9k->21k and one 9k->18k.   (These shelving filters have anti-distortion capabilites, so are much more complex than the simple frequencies imply)   HF is now INFINITELY more clean sounding.   There was an oversight in the EQ.

 

Minor LF correction.

 

Better handling of the old fashioned 'Carpenters'-type recordings with the --fa=L mode.

 

Still, almost all recordings work with just --fa.

 

 

Link to comment
9 hours ago, Skip Pack said:

I have been experimenting away for the past two weeks or so and used 2.1.1F on CD rips from about 7 groups/artists. In all cases, I realized improvements to varying degrees. John's snippets contain variety, but are missing racous/rowdier music. Among my selections were Toots and the Maytals 'True Love', and Albert Collins and the Icebreakers 'Live in Japan', for example. 

 

My usage scenario is probably somewhat different than some, perhaps most others. I'm converting all the songs from an album using a script using the da-win process since my cpu cannot run da-avx. Each song takes perhaps 1.3-1.4 times the playback time to convert. Rather than the simplest default command line my current call is:

 

da-win --input=$outfile --overwrite --output=$newout --info=1 --fa=M --pe90=1,0.75,1.17 --pe90=1,0.75,1.17 --pe90=1,0.75,1.17 --outgain=+6

 

This gives a result that matches the input fairly well in term of dynamics and bass (without the bass bloat). In some cases I have needed to reduce the --outgain to +3.  I do think some of the reports of flatness may have resulted from the quietet output inviting Messrs. Fletcher and Munson to the party when the output is not increased to resemble the level of input played back at the same gain on the same system. And, of course, the congestion that the decoder is removing makes  the original sound louder anyway.

 

To close, I have just finished listening to 'The Lamb Lies Down on Broadwy' by Genisis. While I have always appreciated this, this was the first time I have been able to listen to and enjoy the whole album at one sitting because of the now removed congestion.

 

Thanks, John. I look forward to using each fixed and improved version without fearing, as I have in that past, that I would not necessarily be going back and reconverting all the files repeatedly as the new versions zigged and zagged. 

 

Skip

 

Very interesting notes -- sorry about the 'zigging' and 'zagging'.   I can make all kinds of excuses, but from the standpoint of development, this thing has been a 'Russian Doll' scenario.   Too often, when a new layer of complexity is exposed, and issues resolved, then previous work needs to be revisited.  Sometimes, there have been usage-regressions, but are frustratingly corrections for accurate decoding.   For example, earlier, one could decode a recording at 1,2,3,4,5,6,7 layers and sometimes 9 or 10.  The levels would stay constant, and the apparent EQ would be fairly consistent.  Unfortunately, that was an unfortunately incorrect behavior.*   I found that most recordings are *really* done to 7 layers, perhaps a few at 9 layers.   I understand the rationale, but the specific choices are bordering on arbitrary -- just good choices of encoding techniques.

 

* Earlier versions of the decoder did not line up the layers correctly.  The layers are not stepped precisely at 10dB, but instead there is a (1.5dB or 3dB?) gain needed between each layer.  When doing this, the line-up matches the original configuration, but also the expansion is very intense and REQUIRES accuracy.  (Thank goodness that the DHNRDS DA decoder does maintain input/output gains.)

 

The EQ has been hell, but like in a mathematical 'bisection' for solving a function, we are bouncing back and forth, getting closer and closer.   In recent internal test versions and in many of the 'release' versions, the differences are less and less, and there is less and less need for submodes being specified.   Remember the need for vast numbers of individually specified EQs?   This has been an interesting exercise.   My biggest regret is that I got people involved too early in the process.   Without being so strongly positive on the project though, I might have given up years ago!!!   ADMITTEDLY, there has been A LOT OF BOUNCING AROUND!!!

 

* I intend to write a little doc on the HF/MF and LF EQ today, maybe making a draft available tonight or tomorrow.   With the EQ hints, it should be possible for someone to do their own FA decoder using their 7 DolbyA units.   Sadly, the result would sound like hell when using true DolbyA units...  Also, the anti-distortion processing would need lots of components, simpler EQ would be more practical to build.   It would be an interesting project though.

 

ADD-ON:   I do notice a slight tilt in the response, perhaps +1dB from 9kHz to 20kHz.   This has an odd effect of brightening the recording in curious ways.  I just wanted to let you know, even though the issue doesn't very often manifest as something audible, I DO KNOW ABOUT IT.   The anti-distortion code has the possibility of twisting the effects of shelving, and sometimes needs compensation.   The large-scale, primary anti-distortion code for the HF range has such compensation, and I'll be adding it to the new anti-distortion version of the EQ.   A 'perfect' way of doing the compensation is already known, and is pretty easy to do.  I didn't notice the problem until JUST NOW.

 

About the 'Russian Doll' thing...  The latest revelation is apparent intentional phase scrambling.   The saving grace is that they used a regular scheme that could be undone.  If it isn't intentional, I ran into some very interesting algorithms.   Frankly, I don't know which one is true, just that the anti-distortion stuff works.

 

Also -- about my 'pop' music taste :-).   Sorry about that!!!   I do try to include some London Symphony recordings of various subgenres and also older semi-folk like Simon & Garfunkle.

 

My goal is that 'extra' mastering (EQ) be needed as seldom as possible.   If we need to EQ the result of a decode, I am really trying to make sure that the recording demands it, and it isn't an artifact of the decoder EQ.   I might never make this thing EQ-perfect though, but trying very very hard.

 

This new version MIGHT make you very happy.   Lots of very good things have been happening in the last few days.   As the behavior becomes more and more complete, the quality is zeroing in towards the ultimate quality and consistency.

 

Thanks again.

John

 

 

 

 

Link to comment

Just in case someone wants to download the best possible for today -- if you can, wait approx +3Hrs.   The 'tilt' problem was a bug (using the wrong variable, similarlynamed), and only created a moderate error.   I didn't add the 'tilt' compensation to begin with because the error should have been <0.1dB, but sounded much stronger.   This was a simple typeo along with difficult-to-read variable names.  (The anti-distortion compensation used for other situations could indeed create almost 1dB error.)

 

So, in +3 to +4Hrs at most, there'll be a re-release with ONLY that bugfix (or any others that I hear about before then.)

 

I really want for this to be the basic-sound stabilized version, and this bug is a let-down.

 

 

 

Link to comment
2 hours ago, John Dyson said:

Very interesting notes -- sorry about the 'zigging' and 'zagging'.   

I don't see how it could be otherwise. I worked for a scientific software company for 33 years it sure sounds normal to me.

2 hours ago, John Dyson said:

 

My biggest regret is that I got people involved too early in the process.   

Too early?  Probably. But I don't know how you make that judgement and balance against the lack of broader ourside input. 

2 hours ago, John Dyson said:

Also -- about my 'pop' music taste :-).   Sorry about that!!!   I do try to include some London Symphony recordings of various subgenres and also older semi-folk like Simon & Garfunkle.

I see the decoder as a tool I may well apply to a huge number of albums. The ABBA/Supertramp/Genesis . . . axis seems to be a music grouping were the upper-mid, lower HF range is prominent by its intrisic character. Add to this the abundance of multi-tracking and the use of solid state while that design practice was still under rapid development, it is easy to see how that congestion would arise and be obvious. I think that was 'the proud nail waiting to pounded down'. The FeralA component probably is predominent, but the decoder also probably helps ameliorate any number of other issues.

2 hours ago, John Dyson said:

This new version MIGHT make you very happy.   Lots of very good things have been happening in the last few days.   As the behavior becomes more and more complete, the quality is zeroing in towards the ultimate quality and consistency.

 

2 hours ago, John Dyson said:

The last 3-4 versions have made me happy! That is to say I get an output that I can put into my main system file system without fearing that I will feel compelled to redo it next month. Sure, I have to try several tweaks to get the bass to where I think it's balaced correctly, and to get the output level in the neighborhood of the rest of my music (it's a wide neighbohood, no replay-gain).

 

I'm flumoxxed here -- I can't see the HTML markup here to kill the 2 hours ago, J . . . , and make it look right.

Link to comment

@Skip Pack - Would it be fair to say that you are using the decoder as more of a general tool for effectively "remastering" certain albums, or at least improving the mastering of certain albums, rather than strictly as a tool to correct for "FerralA"?  This is a genuine question by the way.  (mindful of some of the recent posts here!)  I am just trying to understand a little what you are doing, and where you find a benefit.

Windows 11 PC, Roon, HQPlayer, Focus Fidelity convolutions, iFi Zen Stream, Paul Hynes SR4, Mutec REF10, Mutec MC3+USB, Devialet 1000Pro, KEF Blade.  Plus Pro-Ject Signature 12 TT for playing my 'legacy' vinyl collection. Desktop system; RME ADI-2 DAC fs, Meze Empyrean headphones.

Link to comment

Got the fixed release:  V2.1.2P.

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

 

The anti-distortion code gets trickier and trickier because the frequencies in the EQ complex have to be inteleaved instead of just doing straight EQ.   The difference isn't profound for just one set of EQs, but when lots of EQ is done, and there is a lot of associated gain control, the result of doing the careful EQ is a more clean, less distorted sound.


ONE item of note, and I haven't written much about it because it is still not quantified.  The FIR filters and Hilbert transform coefficients are now being shared amongst the 8 threads for each of the 7 psuedo-DolbyA units.   Before, the code was brute force, still mostly is, but I tried an experiment to share the 1000+ coefficient Hilbert transforms, and it resulted in a somewhat noticeable speed-up in the higher quality modes (e.g. --fz=opt and --fz=max.)   I'll be doing this to most of the FIR filters soon.   Also, considering a code re-org that will further improve the locality (allow the full CPU performance rather than cache-thrash.)

 

I'll be doing the demos now.  Also other requests.

Watching on the forum for comments, bugs, and other things also.

 

Link to comment

Snippets done with the V2.1.2P decoder.

Dont' think that there is a terrible decode in the demos this time.

Most of the worst user errors that I might not always have used the correct calibration (--coff=) value.

 

Sometimes mistakenly use -1 instead of -2, which can cause a loss of ambience.

OTOH, using -2 instead of -1, the sound can become a little 'metallic'.  Also, as the calibration goes downward, the dynamics become weaker.

 

https://www.dropbox.com/sh/tepjnd01xawzscv/AAB08KiAo8IRtYiUXSHRwLMla?dl=0

Link to comment

About tomorrow morning's release:

 

The only expected change is the addition of two switches: --pt and --pq.

 

These new switches will be used to tame the 'hotness' of certain POP music decodes.   The DHNRDS DA decoder along with the FA infrastructure respond much much more accurately than a DolbyA.  This means that material that is mastered to sound good when processed through a DolbyA will tend to  sound a little more edgy than when processed through the DHNRDS.   This DolbyA HW defect is known as 'fog', but the DHNRDS in --normal mode has very little 'fog', and in the higher quality modes actually scrubs the fog away. Additionally, the FA mode decoding has some phase compensation that refocuses the various delays vs. frequency, thereby producing a more clean, more accurate result.

 

Otherwise, I cannot find any more serious bugs.  Once the LF EQ could revert to something close to my original design, the last major challenge was overcome.   My prejudice against using 2nd order EQ caused me to keep trying to morph the 1st order EQ into something that starts sounding correct.  THIS lack of 2nd order PROBLEM IS THE REASON WHY I WAS DEPENDENT ON MY HEARING/RESPONSE BALANCE.  With the use of 80Hz 2nd order EQ in one specific place, the problem is now resolved.

 

Possible (not necessarily 'expected') changes for tomorrow:

Minor speed ups;  possible *very minor* LF improvements, since this final code is new; possible overlooked anti-distortion improvement.

 

After tomorrow, unless we find any serious limitations -- there will be no more regular releases, and I will be listening for descriptions of results that are at variance against the sound of an original mixdown.   One caveat:  the sound of FA bass CAN NOT be reproduced, and proper decoding of encoded material WILL PUSH DOWN CERTAIN LOW LEVEL DETAILS AS ANY NOISE REDUCTION SYSTEM WILL DO.   As a side effect of pushing down details that are not very audible on the original mix, the hiss is also suppresed even more. 

 

So, basically -- a very conditional, preliminar 'finis'.   Of course, minor updates will happen.  Maybe minor features will happen, and MOST IMPORTANTLY -- HAVE IDEAS FOR SIGNIFICANTE SPEED UPS!!!   (Already the higher quality modes are faster today than they were 2wks ago.)

 

Major bugs will be corrected without delay.

 

John

 

Link to comment

The planned for 9:00AM release in +1Hr will have to be delayed until 15:00 (+7Hrs) today.

There are ZERO expected actual core decoder changes or core decoder EQ changes.  The expected added features

are in the periphery, but still VERY important.

 

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

 

The base decoding is working nicely, but there are some peripheral pieces that need to be improved, upgraded as below.

If there ARE any changes to the actual decoding side of things, they would be very minor.   The decoding is still dependent

on internal perpheral pieces and the users choices.  Even with the main decoder core working perfectly, bad decoding

results of valid FA materials can still be created.  These changes are in the periphery or in the command line processing,

not the core decoding code or standard EQ sections.   My current focus is about usabiity and handling more of the uncommon

or cases that have not yet been encountered.

 

Technically, there is actually no additional 'DSP' code being added for the new stereo image modes, and the new 'alt' and 'xalt' capabilities can already be accessed by command line using direct controls and special numbers.  It is just that the 'alt' and 'xalt' commands help to avoid needing to remember the numbers used with the 'wia', 'woa' and 'wof' switches.   The only changes to create the 'alt' stuff is in the command line itself.

 

The expected added minor features are:

 

Addition of the --pt=N and --pq=N switches to soften the extremely tight and precise transient behavior.

DolbyA units have a certain slowness in transient response during decoding, so traditionally some material is mastered a little on the 'hot' side to compensate for DolbyA fog.   Not only the DHNRDS can go back and undo some previous fog from earlier encode/decode during the taping itself.   These switches do a very slight 1st order EQ on the post-decoded signal (-0.375dB for each 'N' at 9kHz and 12kHz for --pt.   --pq is slightly different, and will update the StartUsing doc for the details)   It is expected that typically 'N' would be '2'.   High resolution provided (e.g. N=1) for those cases where the 'edge' is not strong at all.   The value 'N' can be any floating point number, but typically using 1 or 2 will make everything good.

 

Addition of the --fw=alt and --fw=xalt stereo image modes along with the narrow/wide versions (e.g. walt, nalt, wxalt, nxalt).

The commonly used --fw=wpop (default) and --fw=classical stereo image controls, apparently, some recordings need a slightly different stereo image...  There are possibilities of image being encoded somewhere in-between 'wpop' and 'classical', and those names will be 'alt' and 'xalt'.   The base names of all of the standard stereo image schemes will be:  pop, classical, alt, xalt.   There are two prefix modifiers:  'w' (wide), 'n' (narrow).   I have not normally documented the complete flexibility of these controls because so far, I have only encountered --fw=classical and the default --fw=wpop (which is not normally used explicitly.)   I just encountered some recordings that I was having difficulties decoding, finding that the is a need for a new named mode:  I will be calling it 'alt' and a modified 'xalt'.   These are NOT used very often.   Later on, I'll define exactly what these modes mean, but each one can be translated into a combination of '--woa=x.xx', '--wia=y.yy' and '--wof=z.zz'.   The numbers are usually related to '2', 'sqrt(2)' or 'sqrt(sqrt(2))'.    Also, 'x.xx' is usually '1.0/y.yy'.

 

These changes have already been made in my local working code, but more testing is needed -- and I want to be very careful about using the new --fw=alt on the problematic recordings.

 

John

 

 

 

Link to comment

Per the previous message, the V2.1.2R version is released.

Linux, Windows versions are available, and also the simple 'StartUsing' guide has been updated.  I fully intend more complete docs as the development slows down more, and my time frees up.

 

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

 

There are two important improvements.   One is the correction of the lowest frequency EQ.   I had previously moved some EQ over a little to make the Supertramp recordings sound better.   Fortunately, I found the correct answer for clean decoding and proper bass on Supertramp recordings, so I moved back the standard EQ.   (Basically, added the 12.5Hz EQ back into the chain.)   It doesn't sound like an important change, but on the contrary, it is VERY important.  (Stereo image problems can make profound differences on the strength of LF, and I found that using the generically correct stereo image, there was no need for extended bass response.)   I know that I shouldn't have earlier done this kind of tweak, but Supertramp recordings are sometimes misguidedly used as a reference, and I am stuck with that tradition.

 

The other improvements are the additions of the --pt and --pq switches.  These switches are used when the decoding result is a little edgy.   These are not intended to perform a large scale HF EQ, but are instead intended to provide a slight compensation for the exquisitely nimble temporal FA decoder behavior.  If you get that slightly overly clear sound, even after choosing the correct calibration number, then try --pt=2 as a first try.   If it still seems like there is some edginess, maybe try adding --pq=1.   Any number can be supplied, floating point or integer, but most likelly, only '1' or '2' should be needed.   Maybe, sometimes a total of 3-4 when using both/either switch, but if you need that much EQ, then there is something else wrong.

 

About the 'alt' stereo image thing mentioned earlier.   After a LOT of testing,  I found the correct generic decoding stereo image to be --fw=classical.  I am not sure yet what the output stereo image should be using --stw (or the --wof approx equivalent) should be.  I'll report back when the results come in.   The 'alt' modes were a misfire.

 

John

 

Link to comment

Will probably not be doing a release tomorrow morning at +12Hrs from this posting time, but have something cool that the decoder is FINALLY doing!!!

 

Many of you know that I have had several decoding 'Windmills' that I have been 'tilting'.

 

*   One had been ABBA, with the ultimate of the mangled 'Dreamworld'.  This is pretty much sucessful.   I have probably the most clean copy of ABBA albums since it was originally mixed.  Also, Dreamworld is now 'tolerable' instead of only a bunch of hash.


*   Also, every time that I tried to decode the old Carpenters albums, there was always the 'sawblade' effect.   That is now TOTALLY resolved...  Even my nemesis of 'Top of the World' is resolved.

 

*   Next, the Carly Simon recordings, with the vocal enhanement, had an edgy distortion whenever I tried decoding.   That is no longer a problem.

 

*   Finally -- and this is the big Supertramp 'audiophile' issue...   On the Supertramp recordings, there was always a bit of vocal distortion, kind of a 'garble'.    Also, there was too much of an vocal 'hitch' on some cuts, as if the vocal 'hitches' were magnified.   The problems are GREATLY mitigated if not solved.

 

I tried all *normal* methods to decode, and the best that I could get was a mild suppression of 'garble', and a minor reduction in the sound of the vocal 'hitches'.   Secondarily, there was a bit of a metallic response balance (and that is a key hint.) HERE IS WHAT I FOUND:  the Supertramp recordings use a non-standard calibration level.   This can happen because the levels were changed (by the distributor) after FA encoding, or they really did calibrate their tapes differently before encoding.   I think that I have mentioned that when the calibration level is too low, there is a metallic sound...   This 'metallic sound' comes from a small upward tilt in response above 3kHz.   Instead of using the normal -coff=-2, --coff=-1, or --coff=0 or even --coff=1...   The recordings need *PRECISELY* within about 0.001 of '--coff=1.13140'.   This says that the actual calibration is '1.13140 * 1.5dB' higher in level, or 1.6971dB higher.   This number is 'kind of ' interesting, because pretty much the standard DolbyA calibration (on the DHNRDS) is approx -27.80dB.   This ALMOST comes close to a -26dB calibration even.

 

About the need for calibration precision on the Supertramp recordings...   As a recording becomes more and more challenging with more dynamic highs and complex mix with midrange, the calibration becomes more and more critical.   There is a great precision in DolbyA decoding, and there is a huge ability to take advantage of dead-on accurate calibration levels when needed.   Even normal recordings need approx 0.01dB accuracy with good standardization, and that is why I hide the calibration numbers inside of the '--coff' scheme, where the argument is usually an integer.

 

Supertramp recordings are pretty dynamic and strongly mix the HF > 3kHz with the midrange because of the prominent vocals.   I finally did an exhuastive bisection search for correct calibration, because I tried everything else to cleanly decode the four Supertramp recordings that I use for testing.  Since my hearing is supurb for finding distortions, it was a bit time consuming, but easy to find the correct calibration.   When I say that --coff=1.3140 is best for decoding the original Supertramp CDs (not the remasters, MFSL, etc), I mean that I tried 1.3145, and it wasn't quite as good.   (I only tested it to +-0.0005 -- but tolerable results come with +-0.001.)   NORMALLY, only integral values for --coff are needed...

 

A purist or total skeptic might claim that the Supertramp results are still not perfect, but some will never be satisified.   The results are better than ANY OTHER PUBLIC COPY that I have found, and I have checked 4 versions of 'Crime'.   On the other hand, those accomodated to the FA sound will never like sound that is closer to an original mix.  When that is true, then there is no risk for them because of stopping FA encoding, because the recording distributors will continue to protect their IP with FA, and are  further trying to digitally protect their IP with MQA.   FA and MQA are two peas of the same pod.

 

There will be new decoder releases in the future, maybe even tomorrow, but none is scheduled.

 

John

 

Link to comment

Unexpected release:  V2.1.2S

(This is the 9:00AM USA EST release for today)

 

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

 

V2.1.2S orrects a mistake in the 20Hz EQ.   Has been corrected to -6dB instead of the mistaken -3dB.   It might seem like a small amount of extra 20Hz bass cannot be a bad thing, but really is NOT GOOD.   The 1st order EQ has a very much wider range of influence than a normal 2nd order EQ, and the sound of such a boost isn't nice at all.   For casual extra 'bass', use a nice 20Hz (or 45Hz seems best to me) 2nd order or higher shelf (tone control.)    The mistaken -3dB instead of -6dB resulted from a test/experiment that was forgotten by a distraction.  (I should have been more careful about checking with the previous internal version before an actual release.)   My development discipline hasn't been very good lately, and with no system testing, mistakes do get through.   Some private demos last night were done with a correction that made the EQ correct in the result.   (The bug can be worked around, if one really wants to use V2.1.2R, by adding this to the command line:  '--pvl=20,3 --pvl=20,-6'.   Don't need to do these extra EQ if you are using V2.1.2S though.)

 

I do expect a planned release within 2 days -- if it helps a problem that I predict.   The highest bands are not band limited, and even though no limits make some DolbyA mode decoding measurements seem better, there is a possibility of some aliasing, especially with FA decoding and the large number of DA passes.   I will be experimenting to see (hear) if the sound is better when using a 0.45 * sample_rate bandwidth limit during some critical decoding steps.   The bw limit is not intended to be a hard limit, but instead an attenuation so that the shorter FIR filter will not create a noticeable slowdown, yet suppress any aliasing enough that it become inaudible.  if there is no difference, a release will not be made for this matter.

 

There might be an unplanned release before the prospective bandwidth limit issue is fully resolved, but I don't forsee one yet.

 

John

 

Link to comment

The release tomorrow will be MUCH more important than originally suggested.

This is a very nice 'tune-up' release, with an official DA version coming one day later.

When testing/reviewing the DolbyA mode performance, I noticed an oddity for FA decoding.   Along with the FA improvments, some iterations

created some semi-associated DA improvements.

 

Explanation for the the original change is below -- other things cascaded.   Note that the decoder was already very good, but as the

precision gets better, the results get easier to achieive

 

One goal for DA is that the input and output levels be precisely the same.  This is important for a lot of things, but even more important for

FA.   Unfortunately, for some darned reason, I removed the scale factor for DA when adding the sqrt(2) scale factor needed between each

FA layer.   Interestingly, even when there is a gain error between layers on FA, the calibration numbers do not change much, but they do change.

 

I plan the release -- a major beautification  in results tomorrow at the usual time (approx 18Hrs from this posting time.)

 

Link to comment

For quality reasons, I decided to delay the release planned about +3Hrs from now until tomorrow same time (9:00AM USA EST time) or approx 27Hrs.

 

At that time, I'll do both a professional version and the consumer version.  There are some minor quality matters that I want to chase down, and a few of them are related to both modes.   Frustratingly, there are differences in the DA processing for DA output and DA processing for FA output.   This is one of the nits that I want to verify.   Basically, for true DA processing, the decoder removes some technical safety nets so that certain benchmarks and measurements better match a true DolbyA HW unit.   However, for FA use, there is a different set of optimum tradeoffs.  A simple example:  bandwidth limits.   For DA decoding, there are normally no bandwidth limits, so noise tests look really smooth like the real HW.   For FA decoding, the bandwidth limits help avoid concatenated distortion products (however little there might be) from accumulating.   On the real HW, there'll implicitly be filters/etc that chop off the troublesome distortions, but when connecting the output of one FA layer to the input of another, it is a good thing to make sure that the BW is limited to just below Nyquist (so products that are just above don't affect further processing.)

 

Every little, small, micro-sized detail is being chased down.   I am still chasing, and I don't want the 'chasing details' to become a game of 'whack a mole' later on.

I do have a few FA test materials, but not many -- and not comprehensive.  The decoder is amazingly good, but I am trying to get it up to the standards of the

DA version of processing.   FA being much more complex, it is also more of a challenge.

 

The goal is that the decoder be available this weekend, and there is ZERO reason right now why it might be delayed beyond +27Hrs from now.  Even IF it is delayed, it

wouldn't be beyond another few hours.  (never know if personal matters get in the way.)

 

* For the FA nay-sayers -- note that ANY other expander that you use will end up with terrible artifacts when doing >40dB of processing, but the FA decoder is amazingly clean...

 

John

 

Link to comment

Technology disclosure:   ALL of the decoding EQ for FA.   it is NOT simple, and will challenge a PhD student for the theory.

 

This is basically the EQ that I have been deriving for the last several years.   If you had DolbyA units, you could theoretically use them (along with the EQ) to do an FA decode.  I'd suspect that DolbyA units have too much modulation distortion and noise to do a clean job, but perhaps that is the reason for all of this interleaving in the EQ?

 

Imagine coming up with all of these numbers, and testing to make sure that the numbers and architecture are correct.  Now, imagine the listening-fatigue!!!!

 

This does not include the DA anti-MD or anti-IMD, because that is even more 'interesting':

 

Attached is the document.

 

decoderEQ-V2.1.2X1.pdf

Link to comment
1 hour ago, John Dyson said:

Technology disclosure:   ALL of the decoding EQ for FA.   it is NOT simple, and will challenge a PhD student for the theory.

 

This is basically the EQ that I have been deriving for the last several years.   If you had DolbyA units, you could theoretically use them (along with the EQ) to do an FA decode.  I'd suspect that DolbyA units have too much modulation distortion and noise to do a clean job, but perhaps that is the reason for all of this interleaving in the EQ?

 

Imagine coming up with all of these numbers, and testing to make sure that the numbers and architecture are correct.  Now, imagine the listening-fatigue!!!!

 

This does not include the DA anti-MD or anti-IMD, because that is even more 'interesting':

 

Attached is the document.

 

decoderEQ-V2.1.2X1.pdf 28.28 kB · 2 downloads

 

Since there were a few downloads, I need to do a small update.  Someone with very astute vision will notice a bug in one of the decoding sequences.   I should have proofread better.

 

Near the beginning, in the 'Beginning of Each Layer', both the 1k and 3kHz EQ, the last shelving filter for each, needs a + instead of '-'.   I highlighted the corrected error in RED.   I am showing the two corrected lines below:

 

-3dB shelf at (MFLFbasefreq + MFLFoffset) - MFLFadoffset

changed to

-3dB shelf at (MFLFbasefreq + MFLFoffset) + MFLFadoffset

 

 

+3dB shelf at (MFHFbasefreq + MFHFoffset) - MFHFadoffset

changed to

+3dB shelf at (MFHFbasefreq + MFHFoffset) + MFHFadoffset

 

Attached the corrected .pdf file.  I checked the formulas and other places where that kind of error might happen...  All should be okay.

 

 

 

decoderEQ-V2.1.2X1.pdf

Link to comment

Release of V2.1.3A.   Hopefully this is closer to the promised results.

Lots of little fixes, including some DA mods to limit the BW of  the modulation products.

I'll be sending this version to pro users also, of course for the DA mode only.

No matter the details (cannot remember them all at this instant), the changes are relatively small (<100 to 200 lines), but

the improvement is VERY profound.

 

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

 

I have been using this version (under another moniker -- V2.1.2X1) for all kinds of recordings, testing, etc.   These results are fantabulous, and more than previous versions:  JUST WORKS.   As the decoder becomes more clean and precise, the submode variations of post-decoding EQ become more subtle and better integrated into the EQ scheme.   That is, the submode EQs are more of the EQ 'family' instead of an EQ 'add-on'.

 

Some recordings WILL need the following:

 

1) for more thin bass, mostly just for earliest Carpenters recordings:  --fa=L

2) for 'unlimited' bass, just the minimum rolloff (most recordings need the rolloff): --fa=B

3) to correct severe cases of thin bass (found very seldom):  --fa=D  (more 'D' values can further increase the bass).   e.g. ABBA 'Voulez Vous' needs this.

Normal recordings (90+% of them, including typical classical/jazz releases need '--fa' without a submode.)

 

All of these submodes 'follow the rules' and aren't just add on 'boost' or 'cut'.   Oddly, a 'bass boost' isn't really just a bass boost, but keeps the shape of the EQ, and changes how the EQ starts in the 1kHz or 750Hz region on down.   Just boost 'bass' doesn't really do what you want.   The internal values for the the LF EQ are a variant of the EQ as described in the 'decoderEQ-V2.1.2X1.pdf' document.  

 

The decoder is much more robust, but an ongoing frustration...  From time to time, very few recordings DO need some ADDITIONAL-ADD-ON EQ after decoding -- probably because of modification so that they sound good in FA form.   This doesn't happen all that often, but, when testing, I did have to do EQ to line up the time delays (I cannot hear response balance very well, per se -- but can hear the effects of profoundly distorted time delays.)   If such EQ was standardized amongst others, I would have added a submode, but these are very specific EQ for a certain sound.  Being an odd case, I'll provide the needed EQ for a test ELO recording (very likely unremastered (or nearly so), pure version of  'A new world record') :

 

A New World Record (1986 JP 32DP 473)

Needed the following EQ to compensate for the vocal becoming buried, recovering a more normal sound:

--pvl=12.5,1.5  --pvl=25,1.5  --pvl=100,1.5 --pvl=250,1.5 --pvh=4k,9  --pvh=4.5k,-9 --pvh=5k,9   --pvh=17.5k,-9 --pvh=18k,9 --pvh=18.5k,-9

 

The up and down between 9kHz and 18kHz is critical, and trying to just average it out won't work.  These settings are very important to make sure that the arrival times are coherent.

 

 

 

 

Link to comment

Announcement:   Decoder is fully functioning and working, better than I had initially hoped, and definitely better than I previously thought it could.

 

The format: 'FA' that it corrects is something like the old-style 'MQA'.   It is a way to obscure the distributors IP, which they don't think that you deserve to listen to!!!

 

Perhaps 90% or more normal, commerical recordings have the crazy, lousy compression that I call 'FA'.   (Feral-A -- a modification of DolbyA, and something that should never have gotten out of the lab.)   Basically, FA got loose, and has damaged almost all consumer recordings.   You might not hear the damage right now, but when you hear relatively pure recordings -- you'll start developing the same disgust about the quality of consumer recordings as I have.

 

Here is my offer:   If a recording is 'FA', the decoder can decode the recording, if not and if the recording is truly 'FA', I'll update the decoder to support it properly.   The major caveat is that not all recordings benefit from decoding (I did learn that), because the FA compression sometimes 'makes the recording sound like it is expected to sound'.

 

If you have troubles using the decoder, and I cannot properly decode a recording with the decoder either, I'll update it.   (The decoder has no 'tweakiness' except a final EQ, which is now solidly determined.)   Some recordings need a slightly different EQ from a family of similar curves.

 

The version V2.1.3A is a watershed event on the project.   In a way, I'll miss the innovation, working towards something unknown, etc. But there are further relatively minor enhancements, speedups and perhaps ease-of-usability improvements coming.

 

As of right now, On the upcoming development version,I have made inroads where the  higher quality modes run perhaps 20-30% faster.   The highest normal quality mode can easily run in realtime on my computer now, but even the faster, 'lower quality' modes give results MUCH BETTER than most of the FA nonsense that was purchased from the distribution.

 

This thing is real, but it might take a little bit of learning and time to get used to what the recording sounded like at mix down.

 

This is no joke, and no longer something that 'hopefully works'...   It *does* work.

 

It takes 16bit,24bit and FP .wav files in.  Outputs 24bit or FP .wav files.

44.1k to 96k, 176k to 192k, 352k to 384k input.

88.2k to 96k, 176k to 192k, 352k to 385k output.  (input rates 44.1k, 48k are doubled on output.)

 

ONLY MAJOR BAD NEWS:   It is Linux and/or Windows command line.

 

Location:

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

 

Link to comment

Below is a repository that contans demos of snippets for RAW cd/digital recording VS decoded.

 

This was done by a decoder that is very close to the same as the released V2.1.3A version, mostly with

enhancements for slightly more quick decoding speeds.   No significant audible quality changes

have yet been made.  There are NO expected significant audio changes further expected on the 

project because the decoding engine is essentially complete, and only minor adaptations to recordings

with newly encountered EQ will need to be made.

(I did use the V2.1.3B not-yet-released version because it does decode more quickly!!!)

 

Important:  the 'decoded' version is closer to the original recording in most cases.   The 'RAW' version has

been rather aggressively compressed.   The compression is a kind of upward compression and tends not

to have the sense of pushing signal levels downwards.   Tjat is: there is little sense of 'pumping' in the compressed,

RAW consumer materials also because the attack/release times are amazingly and almost seemingly impossibly

fast.

 

I suggest doing the comparisons  between RAW/DECODED immediately after one and another and try to go back

and forth rather thanjust listen once.   THERE WILL BE TIMES that the RAW version might initially (and forever) will sound closer

to what is expected.   Also, we ALL have been accommodated/adapted to over 30yrs of FA sound on recordings.

EVERYONE has adaptive hearing, and it might be difficult to initially hear the actual difference and the generally

VAST improvement done by this new and complete version of the decoder.   ANY BEAUTY IS IN THE RECORDING,

and THE BEAUTY IS IN THE PERCEPTION -- not in the decoder.

* The online 'DROPBOX PLAYER' is not very good.  It is best to download the snippets before playing.  There

will seem to be significant defects on recordings when playing them directly from Dropbox.

 

Here are the differences/characteristics to expect:

 

1)  The RAW versions should often have an extreme, almost resonant bass -- approx 80HZ and below.

2)  The RAW versions, esp from older tapes have much more hiss than he decoded versions.

      * the RAW versions have more hiss than what one might expect from professional recordings of the era.

      * Oddly, RAW versions, even from recent recordings, often  have hiss, that hiss shouldn't be there.

3)  The decoded versions have less pronounced ambience and ambience trail-off.

4)  The sound of cymbals has much less 'swirl' and has a stronger, more sound sound like reality.

5)  The bass, mentioned above, has less of a strong associated 'tell' on decoded versions.

6)  Sibilance is better controlled (almost suppressed) on RAW versions.   Poorly configured decoded vocals can have too much sibilance.

7A)  Decoded versions will sound more 'thin' in the 200-500Hz range.

7B)  RAW versions will often sound 'nasal', almost as if the recording has a 'cold'.

8) Since RAW versions are compressed at low levels, they will tend to sound between 0dB and 6dB more loud...

8A)  Given the difference in apparent level, there was a 4.5dB compensation in the demos.  On some recordings, it is slightly too much, on some, slightly too little.

8B) Most of the compression on RAW recordings is at lower levels, so that loudest recordings don't show as much difference.

 

A corollary to all of this:  if there are recordings that have the FA compression, those recordings are NOT ALL DIGITAL.

Any FA encoded recording has been significanly 'bad-touched' by analog electronics!!!!

 

NOTHING IS PERFECT, ESPECIALLY WHEN PROCESSING ALREADY DAMAGED, HEAVILY PROCESSED AUDIO RECORDINGS!!!

The current version of the decoder is as close to perfect, and more accurate than my original goals.  Also, the decoder is

many times simpler to use than any hope that I had when starting the project:

 

BEFORE/AFTER EXAMPLE SNIPPETS:

https://www.dropbox.com/sh/tepjnd01xawzscv/AAB08KiAo8IRtYiUXSHRwLMla?dl=0

 

 

Sincerely,

John

 

 

 

 

 

Link to comment

There will be a new release coming in a few days (hopefully before Friday -- but you know how my goals on that are...)

 

1)  Significant speed-up (same/better quality) for the higher quality decoding modes (for both FA & DA)

2)  Adding a few LF EQ capabilities -- some recordings need slight tweaks.  (probable taste in mastering.)  I wanna keep people from

needing to use the --pvl/--pvh (first order EQ) switches unless really odd recordings.

3)  Sibilance improvement (not really bad, but swishy sibilance is one symptom).   This is the important fix.

 

About the 'sibilance improvement'.   Everything about the decoder IS precision.  Most of the FA magic numbers are even numbers

of dBs, etc.   But, the DA numbers result from HW design and characteristics, not so much from a clear design spec that is publically

known.   Sometimes, it is easy to make mistake with numbers that otherwise require precision.  Happily, the basic attack/release accuracy

is like 0.05%, emulating selected HW components  -- but I was probably not as that worried about other things.

 

Originally, hen w found the relative levels for the gain-curve thresholds, they were measured on a true DolbyA, and then I did curve fitting.  However,

some of the locations of the curves are distorted by the circuitry, filter gains, etc -- along with expermental errors.   The reason for these

differences is related to everything interacting with everything else.   The numbers that we measured were stretched and twisted because  from

the ideal curves, all based on varying circuit gains.

 

Anyway, after all of the reverse engineering, testing, etc of the DolbyA HW -- it appears that I chose the threshold of the HF0/HF1 bands with some error.

I am not  100% sure about the exact error, but it looks like HF0 is about 1/0.95 too high and HF1 is 1/0.9188 too high.k  I was mistakenly using 'even dB's,

but there were some errors relative to that.

 

What was the effect of the bug?   Sibilance would smear a bit.   It is NO WAY as bad as the RAW FA recordings that everyone is used to

listening to, but there was some smear.   It is easy to miss, but I noticed other minor, associated issues when doing my PERFECT Carpenters

remasters.   (BTW -- 1971, the one with For All We Know is beautiful.)   However, there is that decoder defect that needed to be fixed.

 

Here is the difference -- bug has the sibilance smear, and 'improved' is the first order (early) fix.  I am really working on the smallest details!!!

 

 

If I find/fix any more minor issues before Friday, I'll fix them.

 

John

 

improved.flac bug.flac

Link to comment

Demo -- Carpenters 1971 Album.

 

Was going to delay until the morning, but the results seem pretty good.

You can hear her voice, and a silky background instead of the hissy stuff normally lurking around.  The ambience might be different than most people are used to - but the sound is very similar to a microphone and a board, just somewhat processed, instead of over processed.

 

I have tried to fix the 'shifting sibilance' in some songs, but it does appear to be in the recording.   Even when 'cheating', I cannot get it to go away, so I'd guess that the shift is a side-defect of ancient sibilance control, or even tape saturation?

 

Might be better satisfied with more 'boom boom' bass, but whatever is there is in a relatively good proportion.   Adding more bass with 1st order EQ tends to muddy-up the vocals.  So, I tried to be conservative, keep Karen's vocals clean sounding.

 

This is done with the decoder 'fixes' that I mentioned in the previous posting.   The other Album-years that I have done so far are also very good, including the problematical 1970 album.  (Problematical for finding correct balance, not a bad album at all.)

 

ABBA results have also been pretty darned good.

 

Carpenters 1971, snippets (unfortunately need to be snippets!!!)

https://www.dropbox.com/sh/rz3bdy4svdzycij/AAAMS1vbDyw92iyN--UNsMfya?dl=0

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...