'FeralA' decoder -- free-to-use

[John Dyson]

This is a new release that fixes FA  layers >4  (I left a bug in there -- sometimes change things for testing, but forget that it was a scope-probe and not real code.)

 

Also, the HF0/HF1 cancellation is better.   That is one really tricky thing to emulate (the two of the 4 compressors in DolbyA have an overlapping frequency range), and then all of the 4 compressors with BPF are in another feedback loop -- actually in the feedback path itself.   Getting the math right is tricky, and the other problemt is to handle the time delays through the compressors.

 

The HF0/HF1 cancellation causes the problem when decoding material with sibilance in the 6k-9k range, but the sibilance not caused by compensating for DolbyA 'dulling' of the sound.   There are so many imponderable variables, including selected components in that area.   One thing is that the DHNRDS does NOT have any DolbyA fog at all, and some stuff was mixed with the understanding that there will be the fog.   DolbyA itself has problems with accuracy in the 6k-9k range -- so perfection is not really easy to get.

 

Frustratingly, the high quality decoding modes make a VERY VERY VERY profound difference on true DolbyA material, but are only somewhat helpful on FA -- I am not sure the reason for the difference.

I believe that the decoding of true DolbyA material is now EXACTLY *perfect* -- some of the true DolbYA test cases, which were always too bright, now sound EXACTLY like a real DolbyA, except much more stable sounding, more clean, and more detail.

 

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

 

John

[sandyk]

40 minutes ago, Skip Pack said:

Look also for congestion from around 600hz up to say 4Khz when multiple voices and instuments are playing

 Most definitely, although I.M.E. that can also be partly due to the result of a poor quality rip in a PC/Server that is not electrically quiet enough. I have had recent experience in that area where securely earthing the cases of the HDDs and SSDs as recommended by one and a half (Gary)  markedly reduced this , as well as markedly improving the Soundstage. My PC' s metal drive bay used pop rivets between the top and bottom sections, and bypassing these with a direct connection to chassis reduced this. (SSD and HDD have their internal 0 volts(Earth) connected to the case) 

[John Dyson]

10 hours ago, Night Rain said:

Tried those and it sounds muffled.

If the sound seems muffled -- there are two directions to go, remembering to use --cdd (always) when using fcx...   Try fcx=G instead of fcx=g.   If a disk was EQed, you might try fcx=gG, but that is a generally a step-child mode.

 

Also, if the decoding is slighlty dull, or the details seem to be unstable or shift around - then try different calibrations like -46 instead of -44.5.

 

There is one MAJOR issue also.  Some recordings do not want a sequence like htie following:

--44.5, -34.5, -24.5, -14.5

(which is 4 layers starting at -44.5dB)

 

What SOME recordings prefer is this:

--44.5, -34.5, -24.5

(which is 3 layers starting at -44.5dB)

 

It appears that the desired that less compression occur at the higher signal levels.   When doing decoding at -14.5dB, that requires a fairly precise setting, and errors for the higher -1XdB settings, that is where the more profound impairments happen.

 

John

 

[Skip Pack]

I will second John's comments immediately above. I have just rerun the Albert Collins album Live in Japan that I commented on a week or so back. John replied then about this effect (sounding better without  -14.x pass) and I have just run a 4 layer versus 3 layer decode and the three layer with -24.5 being the lowest is clearly nicer. I will also add that the IM reduction makes for a nice improvement -- current line is:

 

da-win --input=$outfile --overwrite --output=$newout --info=0 --cdd --fcs="3,-44.5,fcx=g" --floatout --fz

 

This is the best yet decode I have done, and I will now work on other albums where I have not gotten such good results over previous generations. This is a good stage in this converter's development for many more of us to begin using it.

 

Skip

[John Dyson]

Have a very minor update -- there was some timing wobble left in the HF0/HF1 cancellation.

 

New version V1.6.5D

 

The ONLY change is a minor wobble correction, and the result is a sense that there is less HF distortion.  The 'wobble' isn't actually distortion -- but sounds like it.   The timing wobble where a delay wasn't compensated for by the current loop gain, since the gain changes, it caused a timing wobble.  There was actually already some correction, but it was slightly wrong.   Except for the version number, this is a simple change to one line of code, but worthwhile to update.

 

The difference will be more clean/pure sound:

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

 

John

[John Dyson]

Hopefullyfinal release this week - unless anyone fnds another significant bug..

V1.6.5H

 

1)  Highs are more clean.  Better emulation of the needed feedback for HF0/HF1   (more of an attackrelease type scheme instead of a low pass filter.)  Sibilance is more smooth now.

2) Now works properlywith multiple --fcs commands.

 

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

[John Dyson]

I might need some help from interested users of the software.   Basically, the design has been mostly emperical based upon DolbyA decoder style expansion.   Reverse engineering the scheme has been hellacious, but I think that the FA decoding is now essentially bug-free and complete -- EXCEPT...

 

I am wondering if there is the need for a final HF EQ (a bit of a rolloff.)   The decoder has a flexible built-in user accessible EQ scheme, there is a set of capabilities that provide both 1st order and 2nd order shelving EQ.

 

If the EQ shouldn't be built-in, I might have to be careful about documenting the need for post decoding EQ on some recordings.

 

It seems to me that the last phase of EQ might be missing -- is this happening on ALL recordings, or just a few?   I am suspecting that a single pole rolloff at 9kHz might be needed on the output.   The required EQ could be at 6kHz or 9kHz, or NONE.   Some recordings might not need the EQ?

 

Anyway, when you get your results, and if you find that the HF is a bit too intense, then give the following switches a try:

 

A)  --pi6k=-1 --pi9k=-1

or

B) --pi9k=-1

 

A provides a single pole rolloff between 6kHz and 18kHz.

B provides a single pole rolloff between 9kHz and 18kHz.

 

This EQ thing is trivial in the scheme of things, but I'd like to get your opinion.

 

I have found that scheme 'A' might be useful on both the ABBA Albums, Carpenters and Elton John.   The need for the EQ is NOT a bug in the decoder but might be a feature that I should build-in.

 

John

 

[John Dyson]

There were some delays on docs, but I have learned an important thing:

SOME RECORDINGS DON"T NEED MORE THAN A FEW LAYERS.

 

I'll be doing a new release by the end of the weekend with these new features, and a significantly upgraded anti-sibilance scheme.   Hopefully, I'll be feeling better next week so that I can more easily write the manuals.   Oddly, I can do programming much more easily than writing English prose.

 

I have found that many recordings like to be decoded at 5 or 6 layers, even sometimes 7.   However, I have found some recordings which  do MUCH better at 1,2,3 layers.   This need for very few layers, is news to me, but makes sense.   So, remember, if you have troubles at the normal 3 or more layers, sometimes only 1 or two is needed.

 

Also, given the problems that we have had with excessive dynamics on some recordings, a new feature has been added (geesh -- really DO have to work on the docs, but it is more difficult for me to write in English prose than to program -- REALLY!!!)   The new features are an array of compressors, very stealthy, almost inaudible compressors.   Even though the compressors are VERY VERY HIGH QUALITY, I sure hope that people don't think that I suggest that they should be used on every recording.

 

Currently, some of the compression parameters are fixed, and might optimally be variable in the future.   The new compressors can save the sound on SOME recordings, and not really intended to be used on just every recording.   I did the compressors to fill my time, NOT that they were high priority.   I challenge the userbase to be able to hear any pumping or other untoward effects at compression ratios of 2:1 or less.   Even 3:1 or more can be totally inaudible.   The trick of using excessively fast release times when compressing material to avoid pumping artifacts is NOT needed -- there is no excessive pumping at the sensitive 0.5sec to 2 second release times.   I have not detected a fade-up or gain suppression effects even at 10seconds release time.

 

* In cases of excessive dynamic range, it is better to fully decode material, then re-compress with the compressors -- because the extremely fast DolbyA release time can clobber the natural dynamics of an instrument.  The slower available release times of the add-on compressors can narrow the dynamics without again damaging the sound of instruments.

 

Except for limited flexibility, these compressors might be the best ever written!!!   Might be worthwile to use stand-alone.

 

The compressors shouldn't produce ANY IMD, and only minimal modulation distortion.  There is very effective

anti-IMD code in the compressors, but no anti-MD yet.  These are feedback compressors, so there are fewer

degrees of freedom for anti-MD code.

 

Up to three compressors of each type can be specified, each at different thresholds, different gain limits.

The compressors are placed into the signal chain AFTER the '--outgain' parameter, and are inserted in the

order that they are specified.   The limiter is in the chain just after the last compressor.   The

anti-sibilance is done BEFORE any compressors or limiters in the chain.

 

1)  Single band compressor

2) Dual band compressor, crossover at 275Hz (BEST GP USE)

3) Three band compressor, crossover at 275Hz, 2.75kHz

 

The parameters for --c1, --c2 or --c3 are as follows:

(using the 2 band as an example)

--c2="<ratio>,<thresh-dB>,<mingain-dB>,<maxgain-dB>,<release-time>"

 

The compression ratio <ratio> can be at least 10:1, but I haven't tried higher than that.

The threshold <thresh-dB> is the pivot for increase/decrease gain.

When above threshold, support up to <mingain-dB> of level decreases

When below threshold, support up to <maxgain-dB> of level increases

 

When the release time is specified, and can be anything between 0.040seconds and 10seconds.   All release times

are essentially inaudible, and the only reason for variation is for maintaining short term dynamics.   10seconds

leaves the sound of pianos and other percussion more intact.   At 0.040seconds, the release time is so fast

that it flattens dynamics.  (The attack/release times are dynamic, and the release time shapes the contour

more than being an absolute time constant.)

 

A compressor to make the low levels louder, without significant audible effects at normal, higher listening levels can be enabled thusly:

 

--c2="2.0, -16, 0.0, 20.0, 4.0"

2:1 compressor, increase levels at -16dB or less, never decrease levels above threshold (0.0dB), allow up to 20dB of gain below -16dB, and 4 second release time.

 

--c3="1.4, -9, -6, 0.0, 0.50"

1.4:1 compressor, never increase levels, decrease levels above -9dB, allow up to -6dB of gain, never increase the level above threshold, 0.50second release time.

 

So, hopefully if I don't get worse and start feeling better, because I might even get the release out tomorrow, but Sunday evening is much more realistic.

 

John

[jabbr]

I have decoded Genesis, "Lamb Lies Down on Broadway" [1974 The Lamb Lies Down on Broadway (VJCP-68096-097)]

 

Focusing on the first 32 seconds, the intro piano, then at 10 seconds a HF percussion "shimmering bells" or "tinkles" followed by the "buzzing fly" entering at 16 seconds, and the "tinkles" increasing in volume at 20 and then 30 seconds

 

1: undecoded

2: --cdd -vcs="2,-46,fcx=classical,G"

3: --cdd -vcs="2,'-46,fcx=classical,G" --pif9k=1

4: --cdd --vcs="2,-46,fcx=classical,G" --pix9k=1

 

using Audacity, normalized and then spectrum

[jabbr]

[jabbr]

Next I'm zeroing in more, and using finer density spectrum plot:

Now decoded:

[jabbr]

Those are —fcs=“” not —vcs=“” !!

[John Dyson]

Here, I have some general info about the parameters for using the decoder, along with an announcement of a mild quality improvement.

 

here is something that we can all do something about:

instead of using fcx=g (or fcd=g) as the Eq paramater, try using fcx=G, along with the post decoding EQ: --pif3k=-1 --pix9k=1.

The new settings might be a little more soft sounding, but they sound more real.

 

So, basically it is this:  instead of just using fcx=g (or fcd=g), try:

 

--fcs="<number of layers>, <calibration>, fcx=G"  --pif3k=-1 --pix9k=1

 

A good example might be:

 

--fcs="5,-46.0,fcx=G" --pif3k=-1 --pix9k=1

instead of:

--fcs="5,-46.0,fcx=g" alone.

 

Importantly, on the improved suggestion -- sometimes you might want to change --pif3k to be --pix3k or --pix9k to just --pi9k.   The actual effects of these settings reside in the very poor documentation.   (I'll be working on the docs soon -- I got kind of wierdly sick, so have been playing around rather than working intensively).

 

Also, there is a very subtle change that I made in the attack/release code that appears to make a slight improvement on the transients in the sound.   I think that the improvements are worth distributing a minor upgrade.

The upcoming post-decoding compressors are still a few releases away -- I am still not happy with a few of their behaviors.   The actual compression algorithms are really good, but they aren't ready for prime time yet, and I intend that the main decoding improvements should be made available in the next few days.

 

John

 

 

 

[John Dyson]

On 10/10/2020 at 3:20 PM, jabbr said:

Next I'm zeroing in more, and using finer density spectrum plot:

Now decoded:

 

I have looked at the spectral information, but this comment is NOT specifically on the Genesis spectral information -- just talking about spectral input/output evaluations on FA in general...    This does apply to the Genesis information like all examples though.

 

Unfortunately, spectrums taken over a large number of samples are effectively time averaged.   So, there is a kind of information 'filtering' on reading the spectrum of  DA/FA decoded material where the average levels in the HF will be decreased, in fact the average will often appear to be lower in level than the original FA equivalent. (the average HF level IS often lower -- over the timeframe, the average highs at low levels WILL be decreased.)

 

The peak levels are less different -- they should be closer to being similar.   What happens is that the DA/FA decoding tends to decrease the average levels of the highs, but make the peaks more temporarlly distinct (more sharp in the time-domain.)  This is a typical behavior of multiband compression/expansion.

 

This effect of FA/DA decoding obvious when hearing the hiss disappear (or almost disappear) when decoding older recordings.   The hiss is *low level* HF material, and its level is decreased significantly.   The same happens on most low level HF material.  But, the louder HF stuff has closer to unity gain, sometimes greater than unity gain on some FA stuff, but not so much DA.   DA always downward expands.

 

Otherwise, I will study this specific spectrum stuff again, and really try again to address the issue after I take one more nap starting the day.

I think that offline, with other private attempts -- I might have some, maybe not adequate improvements.

The problem stated by @jabbr  is totally valid -- the original decodes were poor, and it took me a few days to understand that *fact.*

 

The big problem is that I typically start at 3 or 4 layers to decode, and that is WAY WAY too much for the Genesis recording.   The material is slightly FA encoded, where there is a small amount of the FA sound, but it SEEMS to me that I would have been more correct trying 2, maybe even 1 layers.  By using too many layers, parts of the HF are suppressed too much.   Even though the HF peaks are not suppressed as much by FA decoding as the lower levels, by using too many layers or at too high a calibration level -- the middle level HF peaks wil also be erroneously suppressed.  (The tinkles can be disappeared.)

 

I intend to answer the specific comments about the Genesis recordings after I look at them again, and try to make good sense rather than say something wrong (like I often do.)   I am setting a time frame of +8Hrs so that I'll be focused on doing it.

 

John

 

[jabbr]

4 hours ago, John Dyson said:

I have looked at the spectral information, but this comment is NOT specifically on the Genesis spectral information -- just talking about spectral input/output evaluations on FA in general...    This does apply to the Genesis information like all examples though.

 

Unfortunately, spectrums taken over a large number of samples are effectively time averaged.   So, there is a kind of information 'filtering' on reading the spectrum of  DA/FA decoded material where the average levels in the HF will be decreased, in fact the average will often appear to be lower in level than the original FA equivalent. (the average HF level IS often lower -- over the timeframe, the average highs at low levels WILL be decreased.)

 

Sure. I don’t know if these spectral plots are useful, but it seems that we should try to look at measurement and analysis techniques that can detect feralA ... I think it’s going to be too hard for most of us to go through an album track by track and sound by sound determining the optimal settings. I’d like to get some settings that would work for a group in general for example “early Genesis”.

 

Also I’m not sure I’m keen on recompressing rather that recovering a master tape as it was meant to be heard.

[John Dyson]

1 hour ago, jabbr said:

Sure. I don’t know if these spectral plots are useful, but it seems that we should try to look at measurement and analysis techniques that can detect feralA ... I think it’s going to be too hard for most of us to go through an album track by track and sound by sound determining the optimal settings. I’d like to get some settings that would work for a group in general for example “early Genesis”.

 

Also I’m not sure I’m keen on recompressing rather that recovering a master tape as it was meant to be heard.

Yes -- I have put the compressors aside for now -- I wanted to make the better math available (same algorithms- just a different way of looking at the the expander attack algorithms) for the decoder itself asap.

On the compressors, I wanted to use special bandpass filters to the therefore minimizing the time delays and also keeping the relative phase delays between bands small.   Normal IIR filters are a bit more troublesome than what I wanted (IIR filters using bilinear transforms don't work nicely in some cases), and been having troubles getting the quality that I want.  They work okay for 2 band compressors, but not 3 band compressors.  Gonna have to use a different style of band pass filters to get what I want.

 

If the compressed FA sound is what the artist wanted (who really knows), or something inbetween (who really knows) -- then the mildly compressed version might be a compromised between the 40msec flattening of everything and the essentially inaudible 4second crafted release time that leaves some of the percussive sound intact.  Again -- I have tabled the compressors right now -- the single band is 'okay', and the dual band is also 'okay', but I want the dual and 3 band version to use the same technique and to be similar technically and audibly.

 

I think that I found a minor variant on the Genesis recording about the midrange on the decoding result, and has been a previously added capability, forseeing that variant.   Remember the issue a few weeks ago, where I had missed a small portion of the EQ, and pulled back for a few days on a massive review?   That small amount of EQ is not needed on the Genesis recording, therefore the recording might benefit from being 'disabled'.  There are several things that are atypical on that recording -- fewer decoding layers needed, and also this new MF EQ is not needed.   There is a switch (--pemf)  recently added, and also in the current release (V1.6.5H) that mitigates the slightly over intense (+1.5dB or so.) midrange.   I didn't think that this (--pemf) switch to disable the EQ would really ever be needed, but added it anyway.  It is good that I had added it.

 

Here is my best guess (with the --pi3k/--pi9k suggestion also.)   I had earlier considered building in the 3k/9k EQ, and early test versions of the new 'automatic' EQ for the FA decoding DID have the additional EQ, but I found some recordings did not need it, or needed a variant.   I decided, correct or not, that it is better to expose the pi3k/pi9k feature and require the user to know that it is there, rather than to make everything 'too nice' and knowingly spring variants (like the --pemf stuff) that happen so seldom that people forget about it -- INCLUDING ME.

 

(The below has tje calculated removal of the default midrange boost, and also does the semi-normal --pi3k=-1 --pif9k=1 as described in earlier messages.   There is also a new --pi12k EQ also available in the next release, which I found to be helpful on some ABBA stuff, appears to help the Genesis recording -- but it won't be until the next release, coming in a few days, where one can try the --pi12k=1, which is of VERY MARGINAL help anyway.)

 

--cdd  --fcs="2,-46,fcx=G" --pemf=0 --pi3k=-1 --pif9k=1

 

The --pemf=0 removes the 'boost' calculated from the FA encoding itself, but the default 'boosted' version is very often required for after decoding.  The normal state is --pemf=1, which gives the +1.5dB or so, --pemf=0 removes it, --pemf=-1 (probably never, ever needs it), takes away the boost from --pemf=0.   (I don't know the exact number of dB boost, because it comes from two approx 3dB filters cancelling each other somewhere in between their different frequencies.)

*The issue of 'exceptions' that I mentioned above is exactly why I forgot about '--pemf=0' as a sometimes-needed decoding option.

 

JohN

 

 

 

 

[John Dyson]

The  V1.6.6D release is ready.   This is early, and hasn't been tested by the PM users yet -- but I want to make this available ASAP to everyone.   It seems to be REALLY good.

 

Some usage hints -- read the usage doc carefully.   Most of the time, you'll want to use the fcx=G+ EQ, plus additional POST DECODING EQ, using the pif3k/pix3k and maybe pif9k/pix9k and sometimes even pix12k on top of them.

 

Apparently most encoding is done with  the same scheme, but I had mistaken the need for post decoding EQ for different encoding EQ.   It is a complicated thing, but generally just trust that most decoding is best done with --cdd fcx=G+ EQ (within the --fcs switch framework.   Then, like I wrote above, do the EQ needed to clean up the sound after the decoding.

 

Please enjoy, the Usage doc will help a lot, and after POSSIBLY one more technical upgrade (doing native Windows I/O instead of POSIX), then the docs MUST be my priority.

 

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

 

John

 

ADD-ON:  the most profound fix was the correction of some 'wobbles' in the code.  The conversion of feedback to feedforward as a lot of subtle side-effects, and also there was a problem with the Hilbert detectors that I still dont 100% understand.   Also, in the anti-MD code, there was an HF rolloff, which not only had an effect on frequencies above 20kHz, but also had some secondary effects also causing a rough sound in the sibilance.   With these fixes, the results give "live" sound that not even a DolbyA unit can give.   For all of the troubles that the DHNRDS has had, the original DA feedback design had many more!!!

[John Dyson]

I just ran off some REALLY GOOD short samples from some longer private demos.   There is no post procesing other than normalization and conversion from floating point to flac, not even rate conversion -- all the EQ, etc was built-in during the decoding, and all of the parameters are in the metadata.

 

Decoding itself has become bordering on trivial, where all examples used:

--fcsequence="7,-46,fcx=classical,G+"

--fcsequence="6,-49,fcx=G+*"

 

Or other, very similar variants -- all were variants of fcx=G+ (or additional '*'), and possible use of 'classical' mode (which is a difference in stereo image processing.)   I used 6 and 7 layers, but most of the time, 4 layers would have been just fine, and still certainly MUCH better than the original CD/download.

 

The post decoding EQ all looked similar to this:

 

--pif3k=-1 --pix9k=-1 --pix12k=-1

 

Except on the Carpenters, where  I also did a few minor 0.75dB tweaks to soften Karen's vocals.

 

Here are the examples: (should be of politely legal length)

 

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

ADD-ON:  the direct play is much lower quality than downloading and playing on the PC...   If there is 'fuzz' or whatever by playing online, that all comes from the online player.  There is NO fuzz in these examples :-).

 

John

 

[John Dyson]

5 hours ago, John Dyson said:

I just ran off some REALLY GOOD short samples from some longer private demos.   There is no post procesing other than normalization and conversion from floating point to flac, not even rate conversion -- all the EQ, etc was built-in during the decoding, and all of the parameters are in the metadata.

 

Decoding itself has become bordering on trivial, where all examples used:

--fcsequence="7,-46,fcx=classical,G+"

--fcsequence="6,-49,fcx=G+*"

 

Or other, very similar variants -- all were variants of fcx=G+ (or additional '*'), and possible use of 'classical' mode (which is a difference in stereo image processing.)   I used 6 and 7 layers, but most of the time, 4 layers would have been just fine, and still certainly MUCH better than the original CD/download.

 

The post decoding EQ all looked similar to this:

 

--pif3k=-1 --pix9k=-1 --pix12k=-1

 

Except on the Carpenters, where  I also did a few minor 0.75dB tweaks to soften Karen's vocals.

 

Here are the examples: (should be of politely legal length)

 

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

ADD-ON:  the direct play is much lower quality than downloading and playing on the PC...   If there is 'fuzz' or whatever by playing online, that all comes from the online player.  There is NO fuzz in these examples :-).

 

John

 

About my "demos".    Apparently, I tried to do too many layers in the  decoding.

 

People who know about the decoder know that there is a layered scheme, like Russian doll.   Most consumer recordings are made with 4 layers or more, but seldom more than 6 layers.   Unforunately, I tend to push the decoder farther than I should.  Some of the demos were done with 7 layers (-46dB, -36dB, -26dB, -16dB, -56dB, -46dB, -36dB), but I believe that is one layer too much.   The effect is not that of gating, just an 'emptiness' in the sound.

 

I am in the midst of a 'redo' with more sane decoding settings.

 

Really - the decoder can sound REALLY GOOD, making the CD/Downloads 'sows ears' into real silk purses.

 

About +2Hrs, there will be new examples.

 

John

 

[John Dyson]

  (This is a response in the pm group -- noting a new, minor clean-up release and describing it)

 

 

The fixes are:

 

1) Even less fuzz in the sound (fuzz comes from internal filters that aren't scaled correctly because of varying gain -- really difficult to do correctly.)

 

2) the --pi commands, like --pi3k=-1 now accumulate.  So, if you do --pi3k=-1, then a --pi3k=1 -- they will sum to zero.

 

3) Additional of --pi15k, --pix15k and --pif15k JUST IN CASE.

 

This is ALL that is going to be added, and I am using the code RIGHT NOW.   If I wake up in the middle of the night, and awake enough, I'll do the release tonight (it is 20:36 my time right now), but I'll send out the release with VERY VERY slight improvements very soon.   I want to complete this release so that I can send it to Richard.

 

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

 

Also, HERE I GIVE some 'help' info:

 

There is temptation to use --pix form of the EQ at times -- makes the result more 'bright' than the --pif form.  For example, using --pix3k=-1 --pix6k=-1 --pix9k=-1 instead of using at least one --pif (I am testing 'ABBA' Ring Ring right now, when I started with --pix on all three, and now I have reverted to --pif on all three.)

 

Even though --pix causes the EQ to stop at 21.5kHz and -pif gives more filtering by not cutting off till 100kHz, there is still a BIG difference in sound!!!

 

So, feel safe that even though it produces more filtering, you might find that using the --pif version on at least one or two of the post decoding EQ can be very helpful!!!   'pix' meaning 'more bright' isn't necessarily better!!!

 

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

One more hint:

 

--pix9k=1 is the total opposite of --pix9k=-1.   If you mistakenly do a --pix3k=-1 when you intended to do a --pif3k=-1 during decoding, then you can rerun the decoder on the decoding output, in the --skip or --equalize modes, and back-out the --pix3k=-1 by doing a --pix3k=1 and then insert the new --pif3k=-1 afterwards   The two filters --pix9k=1 is totally the opposite and compensate for --pix9k=-1.

 

In the release tonight or tomorrow early afternoon at the latest, it will allow using multiple --pi3k/--pif3k/--pix3k type commands (for all frequencies except 1kHz) and they will accumulate rather than replace each other.

 

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

 

John

 

 

 

[John Dyson]

30 minutes ago, John Dyson said:

  (This is a response in the pm group -- noting a new, minor clean-up release and describing it)

 

 

The fixes are:

 

1) Even less fuzz in the sound (fuzz comes from internal filters that aren't scaled correctly because of varying gain -- really difficult to do correctly.)

 

2) the --pi commands, like --pi3k=-1 now accumulate.  So, if you do --pi3k=-1, then a --pi3k=1 -- they will sum to zero.

 

3) Additional of --pi15k, --pix15k and --pif15k JUST IN CASE.

 

This is ALL that is going to be added, and I am using the code RIGHT NOW.   If I wake up in the middle of the night, and awake enough, I'll do the release tonight (it is 20:36 my time right now), but I'll send out the release with VERY VERY slight improvements very soon.   I want to complete this release so that I can send it to Richard.

 

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

 

Also, HERE I GIVE some 'help' info:

 

There is temptation to use --pix form of the EQ at times -- makes the result more 'bright' than the --pif form.  For example, using --pix3k=-1 --pix6k=-1 --pix9k=-1 instead of using at least one --pif (I am testing 'ABBA' Ring Ring right now, when I started with --pix on all three, and now I have reverted to --pif on all three.)

 

Even though --pix causes the EQ to stop at 21.5kHz and -pif gives more filtering by not cutting off till 100kHz, there is still a BIG difference in sound!!!

 

So, feel safe that even though it produces more filtering, you might find that using the --pif version on at least one or two of the post decoding EQ can be very helpful!!!   'pix' meaning 'more bright' isn't necessarily better!!!

 

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

One more hint:

 

--pix9k=1 is the total opposite of --pix9k=-1.   If you mistakenly do a --pix3k=-1 when you intended to do a --pif3k=-1 during decoding, then you can rerun the decoder on the decoding output, in the --skip or --equalize modes, and back-out the --pix3k=-1 by doing a --pix3k=1 and then insert the new --pif3k=-1 afterwards   The two filters --pix9k=1 is totally the opposite and compensate for --pix9k=-1.

 

In the release tonight or tomorrow early afternoon at the latest, it will allow using multiple --pi3k/--pif3k/--pix3k type commands (for all frequencies except 1kHz) and they will accumulate rather than replace each other.

 

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

 

John

 

 

 

About the 'fuzz' in the current version -- on a TRUE DolbyA, it is naturally much worse because there is no easy way in an analog feedback system to do the anti-distortion tricks that the DHNRDS does.   So, the removal of some small amount of 'fuzz' is really minor, but I want perfection.

 

John

 

[John Dyson]

The new version, with minor qualitative improvements and a few improvements to command line handling.   This is a 'tweak', and mostly the decoding operations sound the same.   The Usage document has also been updated.

 

V1.6.6G

 

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

 

John

 

 

 

[John Dyson]

A new release of the decoder: V1.6.6H had to be done.

 

Broken --limiter, now works a LITTLE better.   Use -6.0dB for the limit instead of 0dB, but at least works fairly well now.

 

Bad EQ screw-up.  Not horrible when it comes to listening, but is something that needed to be fixed.

 

Please grab the new decoder, you won't be disappointed.

This kind of thing is why I have to focus on testing...

 

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

 

John

 

[John Dyson]

New release V1.6.6P...

Major command line bugfix:  fcx or fcd command without any arguments (like --fcs="4,-46,fcx") didn't work, but should have.   Basically witihout any args, the fcx will have more high frequencies and might be an alternative for classical recordings that don't need the 'classical' command.   This bug inhibited doing something that should work correctly.   This is the last minute motivation for this release.  Would be nice to have a formal system test team (this would have likely been an integration test bug though) like back at Bell Labs!!!  Stoopid bug!!!

 

Addition of a --pi4p5k, --pix4p5k and --pif4p5k, for 4.5kHz 1st order EQ.   These work just like the 3k EQ, where the --pi4p5k stops at 9k just like --pi3k does.  (higher frequencies at 9k or above stop at 18k for --pi9k.)

 

Better compressor behavior, a little better limiter behavior.  Compressor sounds more like it should.

Added limiter running display, similar to the decoding running display and the compressor running display.

 

Another try at getting the HF0/HF1 cancellation more perfect.  At this point, I cannot distinguish the tonality of certain test cases on the DolbyA master tapes.   There is more 'clarity', but the tonality is now totally identical.

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

 

John

 

[jabbr]

With "Lamb" I am hearing "tinkles" at 13 seconds using fcs="2,-50,fcx=G+*" --pif9k=-1 but not with fcs="3,-50,fcx=G+*" --pif9k=-1

 

However with all the version changes I need to re-run and be sure., The decode is a bit bright right now but at least I can hear the upper HF details