Jump to content
IGNORED

'FeralA' decoder -- free-to-use


Recommended Posts

1 hour ago, John Dyson said:

 

I have produced a 'NEW2dec' version, using essentially what I plan to be the release tonight (still an open mind on it, though)...   Just to refresh, I'll provide the pointers to the clips:

 

vinyl:

https://www.dropbox.com/s/wgko1yljytaew3z/JustOneLook-vinyl-snip.flac?dl=0

old NEWdec:

https://www.dropbox.com/s/bqp6y53i2tg3h0e/JustOneLook-NEWdec-snip.flac?dl=0

the NEW2dec:

https://www.dropbox.com/s/cn2i4bw26vyiit6/JustOneLook-NEW2dec-snip.flac?dl=0

 

I ran 'NEW2dec' without hearing the new version until just before uploading.   No tweaks, and the decoder adjustment is based on listening to numerous

other recordings, NOW with the +6dB at 80Hz available along with the -12dB @80Hz pre-emphasis and +12dB@80Hz de-emphasis.

Also, the NEW2dec has the more correct HF pre-emphasis, instead of the version that gives a 'halo' effect around the HF details.


Waddya think?

Trying hard at this...  

When I do demos or tests like this, I NEVER 'tweak' to sound better -- this is what I have been planning for the V2.2.3A release tonight.  I can produce more debug versions before the final, but want to keep it really close to what is in the code now.   A LOT of recordings have 'passed the test', but a few are still a little 'strange' (e.g. the old Carpenters 1970 album.)

My mind is open for one more update.

 

I haven't looked at the spectrum in great detail yet -- average spectrums are problematical on compression/expansion like this.   It, of course, all depends on how much expansion was actually done -- so I guess that the averaged spectrum is helpful for a guideline and HELPFUL, just not precision comparison.

 

I'll give my own status report on the spectrum if it has serious problems.   I'd expect that  the bass is a little strong on this version -- but never know until a real measurement, right? :-).

 

John

 

 

The New2Dec sounds slightly better, it's moving in the right direction. Just to be clear: I didn't create the EQ by ear -- these were done to bring the decoded frequency response more in-line with what was on the vinyl clip. I agree that average spectrum isn't the greatest way to do it, but it can reveal systematic frequency errors and so can help pinpoint issues.

 

Here's the comparison between the three clips (red=New2Dec, blue=NewDec, green=vinyl):

image.thumb.png.1f1db1e32a07d264ff3d6c23a99c46de.png

 

What I hear on both, NewDec and New2Dec is not enough clarity around the vocals. The voice sounds a bit muffled and closed-in, like she was singing too close to the mic. I think the relative dip between 1kHz and 6kHz in the decode is what's causing this, and New2Dec didn't really change this part.

 

Link to comment
1 hour ago, pkane2001 said:

 

The New2Dec sounds slightly better, it's moving in the right direction. Just to be clear: I didn't create the EQ by ear -- these were done to bring the decoded frequency response more in-line with what was on the vinyl clip. I agree that average spectrum isn't the greatest way to do it, but it can reveal systematic frequency errors and so can help pinpoint issues.

 

Here's the comparison between the three clips (red=New2Dec, blue=NewDec, green=vinyl):

image.thumb.png.1f1db1e32a07d264ff3d6c23a99c46de.png

 

What I hear on both, NewDec and New2Dec is not enough clarity around the vocals. The voice sounds a bit muffled and closed-in, like she was singing too close to the mic. I think the relative dip between 1kHz and 6kHz in the decode is what's causing this, and New2Dec didn't really change this part.

 

I'll have to think about this -- because the 'decoding' doesn't do very much where there is a difference between vinyl & decoded  - it is coming from the recording itself.   There isn't much to tweak in that region  (yet!?!?!)

 

I don't want to add gain in that region unless I have a reason to (Same as the bass -- I thought that I had already done the bass, so I didn't want to add more.)   I need a theoretical basis for it.   I AM WILLING TO ADD GAIN, if I can find a reason to -- and I do look for a reason.


FA has to be *relatively* flat in comparison with 'decoded' (or hopefully, 'pure') because otherwise would be intolerable.   The big difference on FA are at the much lower levels.


Subjecitve viewpoint (untrustworthy): When I heard the vinyl version, I felt it to have a 'telephone' type sound, where the lower highs (upper midrange) was boosted. 

 

ONE REFERENCE VERSION IS THE FA SOURCE ITSELF, must have similar signal energy to the original, but not good for precise matching.

 

On FA CD source, the peaks and energy density should be SIMILAR to the decoded version -- justa  little different -- a little compressed, most action at less than -20dB (more serious action at -30dB.)   (The thresholds start at -23dB, and start getting busy at -10dB below that.)

 

So, attached are the curves:   Top is the CD, middle is decoded, bottom is vinyl.   The only curve with an accellerated HF rolloff is the vinyl version.  It looks EQed or high level midrange compressed relative to the other two.   To me, it appears that the vinyl version (bottom) might be at variance for the highs.  (I checked the vinyl version for an LF reference, but that is not entirely valid without even considering the lower HF/upper MF (the 1k to 4kHz range.))

 

* TOP: FA Boosted/compressed low level LF  (Should be almost +30dB relative to decoded version at lowest 10Hz type freqs).

* MIDDLE: DECODED The decoded one is obvious --with  the LF rolofff, and that is to be expected

* BOTTOM: VINYL slow rumble/noise on the bottom:

The mild 'brickwall' look on the vinyl version bothers me.

 

Methinks that the vinyl version is more at variance.

 

1498542984_Screenshotfrom2021-04-0512-28-15.thumb.png.8084a6a98c024a0d7257da5ea2b33020.png

 

Link to comment

There is currently a set of before and after snippet demos at the usual dropbox location, but after careful consideration, I found the EQ on Z2.2.3A to be incorrect.   The error was small, but was definitely there.   Basically, there was too much density at the lowest frequencies, therefore producing a muddy sound in the bass.   I made a very small adjustment (in the lowest bass, 1.5dB is very slight), and that change gave a much better, more tight bass, while still maintaining the lowest bass frequencies.

To quell concerns, all changes were made with  the '3dB' and '6dB' EQ steps, and trimming the lowest frequencies by 3dB/6dB/9dB changes below 20Hz.   Also, there was a change to the 2nd order EQ intended to compensate for the 80Hz boost, which was moved from 18Hz to 15Hz (-6dB at 15Hz to compensate for the +6dB at 80Hz.)

 

With all of these changes, the low bass is of similar strength, but sounds much more tight, less muddy/sloppy.  (I truly hate these subjective tests.)

I have the true, prospective V2.2.3A ready to build on Windows, and am doing the 'demos' decodes on Linux right now.   My mind is still open on the boosted 3kHz range, sharper rolloff scheme of the vinyl, and am prepared to do something about it, but need better basis for a decision.

 

I had only gotten the vinyl version from the other group because being interested in the bass, but likewise, it would be wrong to check the bass without considering the high end.   I had initially blown-off the high  end  on the vinyl, because it sounded like a 'telephone'.  On the other hand, it just might be correct.   At this point, I must stick with the response closer to the original FA rather than the vinyl -- I don't even know the provenance of the vinyl version, and not willing to search the 'bad places' for a copy to compare.

 

So, the +6Hr release is looking really good unless I can find a solid veto!!  I am looking for one!!!

 

John

 

Link to comment

After a lot of careful comparisons and evaluations, I have taken A2.2.3A and labeled it as V2.2.3A, and it has been released for several hours now.

I have not found an audible flaw, esp when considering the FA source material.

 

There might be some criticisms -- sometimes the bass is a little thin compared with the FA, but it is very similar to the best quality recordings that I have heard.   The  highest highs are sometimes a little strong, but my usual answer to that is a slight (very slight) -0.75dB at 9kHz filter.   These minor differences are mitigated by 'finishing touches' because I will NOT add my own taste to the decoder -- I must have justifiable reasons to add EQ of any kind into the decoder.   I have run out of reasons, and the decoder does sound VERY GOOD, therefore it is finished.

Strong justification is now needed for significant changes in audible characteristcs.   These justifications can be argued and I can be convinced, but MUST find a valid technical reason for making the change.   For example,  I really thought that I already had added the +6dB at 80Hz EQ, and it REALLY WAS in the code.  I had mistakenly disabled it.  In that state, I would NOT just willy nilly add another +6dB, because it could not be justified.   HOWEVER, I could justify correcting my bug, and re-enable the already existant +6dB at 80Hz.  Another change which is still 'green' -- currently I am using two -6dB 80Hz pre-emphasis and equiv +6dB on output.  That MIGHT be wrong, but after a lot of testing, found it to be the best choice so far.  It will be relatively easier to make an EQ change there instead of the MF range or the highs.   There is an EQ at 3kHz to 9kHz right now, but that is the strongest of my various prospective EQs because it mitigates bad sounds from dynamics processing the very best of all choices (including NO eq at all.)  My mind is open, but agian, I need VERY STRONG justification and must know that no new artifacts are created.   All of my choices are about minimizing ugly sounds, ugly 'tells'.

 

Bottom line -- there is a theory of operation in the decoder, and it is NOT ad-hoc AT ALL.   Discipline has been needed because there was NO SPEC and without spec nor discipline, the decoder could not be completed.

 

Therefore -- here is V2.2.3A, and it is essentially THE RELEASE.   It is GOLDEN, and changes are only made if can be justiifed (e.g. moving the EQ a little bit because of a missing dB at 30Hz -- THAT Is a justification.)  Just 'needs more bass' -- that is NOT a justification.  Gotta understand WHY the output needs more bass!!!

 

Snippets for V2.2.3A: (the directory name and filenames reflect the version of the decoder that created them)  DONOT mix up a decoder version with the wrong demo snippets!!!

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

 

The FA decoder V2.2.3A release (hopefully more docs will be coming in 1-2 weeks, not months):

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

 

If you see a V2.2.3B instead of V2.2.3A, that simply means that I found a justifiable improvement.  It will be difficult to improve much on the current V2.2.3A version.

Source will be coming in months, not years.   There is a lot of readability cleanup, and might even be a new-style anti-MD that runs a LOT faster, but the basic SOUND

will NOT change.

 

 

 

Link to comment

Very quick impressions:

 

First, you did no harm to the glorious vocals, and perhaps even improved them a touch.  Just listen to the two versions of The Sound of Silence, no comparison in terms of how much more I subjectively enjoy the decoded one.  (Don't know if there's a difference in overall loudness - if so, that could be at least partially responsible.)

 

Second, the problem with the bass has been ameliorated somewhat but not totally to my ears.  On "Here Comes the Sun" (noting before I go any further the naturalness of the guitar and the lovely treatment of George's vocal in comparison to the raw snippet), just concentrate on McCartney's bass line.  It seems to me the overall bass level has gone up relative to the last decoder, and the lowest notes may even be the slightest touch bass-heavy by now.  But listen to how the volume of the bass in the decoded version diminishes as the frequency of the notes goes higher to a *very* noticeable, to me unnatural, extent.  Compare to the raw version - the bass notes are much closer in volume over the frequency range.  Not precisely equal, but not diminishing to nearly the extent as the notes go higher as in the decoded version.

 

Again, this is just a quick listen on desktop speakers, and obviously a subjective impression.  I don't know if measurements would show that impression to be correct.  But that's what I'm hearing.  It's great stuff overall, but I'd love to hear the higher bass notes sounding a bit more equal to the lower bass notes if that can be done without mucking everything up.

 

(Just to note that the overall subjective improvement is so marked I feel a bit ungrateful voicing any criticism at all - it's solely in aid of helping things improve if possible.) 

One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment
20 hours ago, John Dyson said:

I seem to remember 'Roberto' on the FBSD mailing lists.   Are you the same guy?

 

No, I do not think I even posted to the FreeBSD mailing list.

 

20 hours ago, John Dyson said:

Sorry for the rude or (actually frustrated) response.   I have been under a lot of pressure trying to fix heisenbugs. 

 

So not worry, I was assuming this was mostly out of frustration. Also, I work a lot with American colleagues and even if I am European I do not take it as rude to talk about wages (even though on this side of the pond it would be inappropriate, but I got some "inter-cultural communication" training from my previous employer to properly contextualise certain behaviours).

 

20 hours ago, John Dyson said:

Oh well -- working veryhard on the release.

 

 

Good luck. As for helping with the math, apart from the fact that I am quite busy, it is not specifically my field. I fear you may have an unsolvable problem at hand – definitely an exact solution is not going to exist. But I would be delighted for my fears (not persuasions! just fears) to be proven wrong.

Link to comment

New, minor release:  V2.2.3B

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

 

I was afraid of this, a minor, but important bugfix.   A phase of de-emphasis was done slightly incorrectly as explained below:

--

 

Bugfix from V2.2.3A to V2.2.3B...
 
Code change:
Error in the EQ for the HF pre/de-emphasis.
 
The ‘past-12k’ side of the 3 phase de-emphasis started at too high a frequency
code change below (approx line 8235 of audioproc.cpp):
 
         //double fcor2 = iminfo.f1 * gcor1 * gcor1;  V2.2.3A -> V2.2.3B
         double fcor2 = iminfo.f1 * gcor1;
 
        Basically, the compensation for the 12kHz de-emphasis started at approx 1.19x too high in frequency.
        This *VERY SLIGHT* error created a mild, metallic effect in the sound.   It could be partially corrected
        by a small rolloff at about 9kHz, but this is a true fix.
 

 

 

Link to comment
1 hour ago, mocenigo said:

 

No, I do not think I even posted to the FreeBSD mailing list.

 

 

So not worry, I was assuming this was mostly out of frustration. Also, I work a lot with American colleagues and even if I am European I do not take it as rude to talk about wages (even though on this side of the pond it would be inappropriate, but I got some "inter-cultural communication" training from my previous employer to properly contextualise certain behaviours).

 

 

 

Good luck. As for helping with the math, apart from the fact that I am quite busy, it is not specifically my field. I fear you may have an unsolvable problem at hand – definitely an exact solution is not going to exist. But I would be delighted for my fears (not persuasions! just fears) to be proven wrong.

PS:  the only reason why I felt free to mention 'income': 

DEEP in past history...

It shows that I am not a fool, and not just a regular, run-of-the-mill engineer. (more R+D, not so much developer.)

 

The decoder project was perfect for me -- except it was too much to handle because of the total lack of specs on the 2nd phase, and the 1st phase of the development had NEVER been done before.  (that is, there was actually fear by others that an accurate DolbyA decoder was impossible, because others had tried and failed.)  The Sony DolbyA patent is totally laughable, and I sure hope that no-one is dependent on that patent alone.   The DHNRDS scheme is a 'control systems' analog more than an analog design conversion.  Therefore, by opening up the control system from feedback to feedforward, even with the great intricacies and complications -- there are more degrees of freedom, making it easier to do anti-MD schemes with very long time delays.   As you know, delays in feedback loops are majorly problematic.   In fact, the original DolbyA HW has a delay in the decoding specific scheme, therefore creating quality problems.  (Most engineers probably woudln't even notice it from a review of the schematic, but a lot of audio people back in the '60s DID notice quality problems.)

 

The real development only started 2yrs after I determined approximately the damage to the recordings.  I saw the DolbyA signature in the recordings, but didn't realize at the outset that there were MANY DolbyA signatures in the recordings.   This is probably why I found a level-periodic nature to the needed calibration levels (approx 10dB steps -- I should have realized earlier on that they had stacked the enocoding.)


The project kept going on, development starting at approx 2014, creating garbage DolbyA deocoders until about 2017 -- I had NO idea about the needed precision.   I really DO have designs for very advanced compressors/expanders, but they didn't match a DolbyA.   About 2017-2018 the DA decoder started being fairly accurate.   The FA project had always been in the background, but when working on difficult things, one must compartmentalize.   I fully opened up the FA project in approx 2018, and went from 1 layer, various forms of layering.  After testing, looking for tells, finding needs for EQ, pre-emphasis/de-emphasis, now there is a truly accurate FA decoder.   The people at AS have only seen about 1.5Yrs of the frustration that I have been enduring.  It probably takes an uncommon personality to maintain focus for so long --maybe some might claim that my personaity is defective, on the other hand, I wonder about the short attention span in many people :-).

 

 

Link to comment

Here are new samples from the new release:  V2.2.3B.

These have the HF correction, along with specific decode mods for the Tijuana brass stuff.   There was relatively more bass than on the FA version,so I used the --fa=LL control.

 

Also, there was too much bass on the Beatles stuff, but also on the FA source, so I must deem the decoder as being correct.

 

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

Link to comment

There is a V2.2.3C release -- fixes TOO MUCH BASS.

 

 

I truly think that the lowest bass has been too strong.  It is repressively strong, but the more normal parts of the bass are okay (like around 40-60Hz.)

So, I did something that I do not like doing:  I used my subjective opinion and cut the bass a little.  I really had to do that, was getting negative comments.

 

 

Link to comment

Maybe made some progress on the bass issue, and might be more simple than I had thought.

Just got some encouragement from someone on this forum (will use his screen name with permission), and did a revisit on the LF EQ.

 

As you know, the LF EQ has been crazy-making.  It has been incredibly complicated, and a real 'downer'.   I don't know if you know what

I was doing, but one big blast of EQ after doing the full decode.   This schema happens to be correct for the HF region, but the MF region

needs a special EQ per step.

 

I had been doing the LF in one big step a the end, just the same as the HF, but NOT the same as the MF.   The LF EQ has been big and ugly.

I really SHOULD have put my 'common sense' hat on and note that the LF EQ has been TOO complex.

 

After the smidgen of encouragement, with both extreme desperation, and a slight improvement in my spirits, I tried a totally different alternative -- do the LF EQ on each step.

That is about as simple as one can get.   On each layer, the amount of EQ is MUCH smaller than doing it all on the end.  How much EQ, and what frequency?

I don't know yet, but I just tried two -3dB LF rolloffs at 80Hz, and the sound was pretty good.

 

As you know, 'pretty good' is NOT good enough, this needs to be *accurate*.   I guess I have a day or so of work ahead of me..

 

YOU KNOW WHO YOU ARE -- thank you for the encouragement.   I have needed some kindness...

I guess that  my mind is different than most people

 

 

 

 

Link to comment

Gonna try to do a release in +4Hrs, if not -- +12Hrs after that (+16Hrs.)

Probably best to expect +16Hrs.  I don't want to waste anyones time any more.

 

Total redo of the LF EQ.

 

With some emotions encouragment getting more emotional energy,

I tried a different EQ approach -- got a 'lock-in' like on previous portions of the EQ

instead of the recent 'tweakers delight'.   I do not playing 'whack a mole' and that is the manifestation of 'tweakers delight' :-).

 

Instead of that monster EQ list (between approx 750Hz down to 20Hz and below) with a myriad of -3, -6, -9dB steps..  YUCK!!!

 

A new EQ list -- but on a per-layer basis instead of after decoding...  TADA:

 

1st order: 500Hz, -3dB

2nd order: 80Hz, -3dB, Q=1.0

 

That is it, but per layer.   This solves a few painful problems

1)  LF pre-emphais, de-emphasis

2)  LF EQ.

 

I knew that there had to be pre/de emphasis, because the shape of the LF needed 'sharpening'.  I could hear it,

but couldn't quantify because of the variability of my hearing.

 

This new design is close to 'locking-in' instead of trying to 'tweak' for the right sound.

 

THIS SEEMS CORRECT.   On the original LF EQ scheme, I kept searching for the right answer, but couldn't find  it

until now.

 

 

 

Link to comment

John,  I listened to the snippets and ran my own set of test files through 2.2.3C, and feel they are the best yet partidularly with respect to the textures on the low bass. Your comments about the 20hz to 40hz range being important makes sense to me as they probably affect everything up to 160hz to 320hz qute a bit. I like bass, but I don't have a setup that really goes much below 35hz, and I am content if that seems right. While many may want even lower frequencies to be present and correct, very few have systems that will play them correctly or even audibly. The joy of music is fully available to me if 35hz up is fully present and correct.

Link to comment
3 hours ago, Skip Pack said:

John,  I listened to the snippets and ran my own set of test files through 2.2.3C, and feel they are the best yet partidularly with respect to the textures on the low bass. Your comments about the 20hz to 40hz range being important makes sense to me as they probably affect everything up to 160hz to 320hz qute a bit. I like bass, but I don't have a setup that really goes much below 35hz, and I am content if that seems right. While many may want even lower frequencies to be present and correct, very few have systems that will play them correctly or even audibly. The joy of music is fully available to me if 35hz up is fully present and correct.

Man - you wouldn't believe how screwed up my previous approach was.   The only reason why it was as good as it was - I worked HARD to get reasonable results.   Does that sound like something was wrong?   Well there was a serious problem -- I was doing it wrong.  I worked REALLY HARD and should have worked SMART instead :-).

 

Here is the deal -- in a casual conversation with another person on this forum, and the positive vibes, I got a really good idea...   Instead of doing the EQ AFTER decoding, do the EQ AFTER each layer....   BINGO!!! (MF eq is already done after each layer, but HF is done after all is done.)

 

I know that I might have mentioned the propsective answer about two EQs, but the exact numbers were wrong.   Basically, it turned from about 10 EQs after decoding to about 2 simple EQs after each layer/step.   The 2 simple EQ ended up being trivial, plus another bonus.

 

If you notice, the 'shape' of the bass was wrong -- it just wasn't 'right' (that dog don't hunt.)   I knew that there was something wrong, but couldn't see the answer.

 

By doing this two EQ between each layer (plus one final, simple EQ) -- the 'shape' of the bass was better also, because the gain control could get more control over the bass (this is hard to explain -- basically, the bass is the right level, and has a better sound!!!)

 

The V2.2.4A demos (actually V2.2.4B, mislabled) are online now.   I think that I am finally satisfied, and not 'desperate' like I was.   I kept trying to 'get feedback', but finally, there was a magical nugget (maybe that correspondent sent ESP to me :-)).   One of the private conversations was kind (most are), and something good happened :-).  Anyway, I don't think that anyone will have major complaints about the LF on the  V2.2.4B release with the changes that I tried to describe above.

 

BASICALLY -- result of working SMART instead of working HARD!!!

I expect the release at 2100 Eastern USA time (approx +4.5Hrs).

Frankly, I already have V2.2.4B in hand -- just holding off for any bugs that I can find...

 

 

Link to comment

The new V2.2.4B decoder is available.   Much better bass.   Like usual, might not be perfect, but seems to have a more correct level, and has a more correct 'sound'.

There isnt a new 'StartUsing' doc yet -- there really isn't any changes, but as the project settles down, there will become a better document in general.   Just use the existing 'StartUsing'.  Literally, there are no real difference in command 'choices'.   All differences are in signal handling (a major difference in bass, minor improvement in HF.)

 

One thing that you might find, since there is better control of bass, there is much less need to use the bass modifying submodes.

 

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

Link to comment

I have an announcement and question...

 

First, the announcement -- on one my my 3rd level tests, I found some LF gating (very very low level piano), and after some test choices -- found that an 80Hz and 400Hz EQ had to be changed to 75Hz and 500Hz. (1st order EQ).  Believe it or not, that made a substantive difference in limited situations.   Also, after that change, I noticed that the shape of the bass was damaged  (e.g. the bass on Rumors album was wrong).  Therefore I revisted some of the other compensatory bass EQ -- found that it needed a Q=0.8409 instead of Q=1.0.   These changes are WELL within being reasonable.   All of the structure appears correct.  I am reruning tests on less difficult materail.  If all works out, might be able to get the release out this morning, but wont' promise.

 

I have another layer of retests -- per the question below:

 

I have question for those using or testing the decoder....

How are the highs?   I found a minor error, supposedly corrected in the V2.2.4B release, and there is a theoretical basis for the correction, but MIGHT be wrong.

 

Here is what to expect -- IF the correction is wrong, the highs above about 12k->13k might be slightly suppressed.  I am speaking of about -0.5dB at 12-13kHz, then up to about -1dB at 20kHz?   Even though myhearing doesn't go anywhere near the upper end of the range, I can detect a slight difference.   The change appeared to be beneficial, but my hearing is in no shape to make a definitive judgement.   I have found that the sound is very sensitive to the 1st order EQ in the decoder.   Great care and good insight is important for the total sucess.  Again, the correction has a strong theoretical basis -- I have no motivation to tweak anymore since the LF problem is now essentially fixed.


Right now, we are far into 'partial success', and might even be a fully successful experiment.   However, I want 'perfection', as I think everyone does.

 

I do better by working with 'design philosophy' instead of tweaking.   (The LF fix 'locked-in' instead of needing 'tweaking'.)   There could still be a minor error in the LF, but a LOT of things were fixed.  There is a theoretical basis for a *potential* need for further change to LF, but I can not justify it without someone elses' input.  I cannot hear the need for further mods, and the LF balance appears *fairly* close.

 

The important thing that this fix corrects -- the low bass disappears when it isn't needed, then reappears as needed.   The previous versions had too much low bass all of the time.   The decoder needed more control over the low bass, but I didn't know how to do it until making the EQ change.   The EQ change gives the decoder a lot of control over the low bass.   On a typical recording with significant bass, there is now about a 6-10dB modulation of the low bass level, sometimes higher.   This modulation also rebuilds the bass envelope.

Link to comment

Sorry about this -- per the comments in the previous post, I have determined that both possible defects are worth another

release.  I am praying that this is the last for a while.   The bass has been a problem and needed a final clean-up, and the HF fix is a further

correction to the earlier HF correction.   The previous HF correction was incomplete, but this last HF mod is basically removal of an

SQRT operation on a gain parameter -- nothing is structurally changed, not even addition/removal of any EQ, just a few

mods of parameters from one standard value to another standard value.

(When theses kinds of changes are made, most of the time the difference in level is sub-dB.  sub-dB errors are really important here as

they are very audible.)

 

The new release is built, but I need to run lots more tests before 5Hrs from now, so I'll be working on it.

 

Link to comment

V2.2.4D is available.

These fixes were encouraged by two of the project's users/supporters, and somehow the LF fix happened when I was discussing the matter with one of these users.   I don't know why I couldn't have done the LF EQ correctly before.    There has been a LOT of good people helping the project, including the DA project partner.   I have added a FEW IDs to the using document, and as I can remember, will add more.

 

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

 

It fixes the minor bass mismatch (we are far into the sub-dB error there now.)   I might have hesitated too much about rolloff around 20Hz, but decided to be a bit conservative touching the theoretical' EQ.   There is still more than enough EQ to handle suppress less than 10Hz type stuff.   (The decoder creates NO new <10Hz stuff itself, and in fact produces very little excess sideband energy from gain control at all, even under cases of extreme dynamics.   One reason why I think much about <10Hz is for vinyl, which can and IS FA encoded at times.  )

 

Also, the HF EQ correction was *slightly* wrong and create about a -1.5dB error at 20kHz, but more important is the corrected  0.5-1.0dB error at 12->15kHz.

Haven't updated the 'StartUsing' document as the only change is a description of the corrections.

 

About usage:

There is no need for the '--fa=L' submode, simply because the LF bug that forced using it is now corrected.   The LF band (<80Hz) is now under better gain control because of more correct pre and de-emphasis -- so, the cases where there is too much bass are now handled by the internals of the decoder.  It wouldn't EVER have been a problem if my reverse engineering on the bass (now, a very simple 500Hz and 75Hz) was correct to begin with.  Before, I used a large sequence of EQ after decoding, which became very complex because of the numerous expansion layers with the encoded compensatory EQ for the DolbyA devices.   My previous LF EQ was NOT mirror image from the encoding, now it is an image of the encoding process.  (These results 'locked-in' -- any error in the LF EQ essentially produces unlistenable sound -- think decoding DBX on un-encoded material -- errors can make it THAT bad.)

 

On normal consumer recordings, I don't think that there is ANY need to vary from the default --coff=-2 and the --fa commands anymore.   Since --coff=-2 is the default, you won't usually need to specify it.  If the recording has been normalized, or EQed after encoding, then all bets are off though.   So, we have the EQ and calibration levels now mostly hidden from the user -- HORRAY!!!

 

This release is on the knife-edge of being needed -- this is a correction of small errors -- much more small than the errors in most recordings anyway.

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

 

Here is an especially clarifying example -- the original 176k consumer obtained recording, and the decoded version (sounds more like when in the studio.)  The major flaw in the decoded version is a slight amount of hiss modulation.   However, the cymbals are pretty darned good -- that takes good tracking of the gain control.

 

RAW:

https://www.dropbox.com/s/3c6nm2w4a5r4pbc/01-Blue Rondo a la Turk-RAW.flac?dl=0

DECODED:

https://www.dropbox.com/s/luahrp6qyjbyo52/01-Blue Rondo a la Turk-DEC.flac?dl=0

 

 

 

Link to comment

The V2.2.4E version is being distributed now, and it passes my tests for bass and HF clarity.  (There has been a persistent problem with HF, much less pronounced than LF.)  This is a complex thing in general because of the crazy nested unfolded control systems -- just complicated.

 

The HF has been a bit tricky especially because the dynamic gain of the expanders mixing with the pre/de-emphasis, and how to do the de-emphasis after

the pre-emphasis.  Where exactly to place a needed 'bump' in the response, this is not normal, simple stuff that you might hear about for stuff like DBX

or pre-emphaiss for certain encoding schemes.   There is a subtle nature and the fact that the original design engineer might have made obscure choices.

 

The LF was actually simple, once I took the correct approach.  All it took was 'positive energy' from someone -- this has been such a downer to give

a gift that seems to be totally misunderstood.   The complexity probably not able to be imagined by even some technical people -- this is truly challenging

stuff -- and IS A GIFT.

 

I think it is all correct now -- so grab it.

I plan to disappear for about 1.5wks, except for quick lurking.  I am only looking for program failures as the quality in my experiments is

about as good as the current design can do.   The quality is actually BETTER THAN POSSIBLE when using conventional techniques.

Part of the disappearance might be to work on some things that are simple enough that the design and using might be easier to understand

for the average engineer.  One thing that has REALLY bothered me is the lack of a public verison of a general purpose binliear S to Z converter.

I know how to do it, but might take a day or so (it is a cool set of algorithms, but can mitigate a lot of troubles for a DSP engineer, not depending

on some kind of hack software that costs multiple thousands.)

 

However, might have some really good news -- I have a line on an anti-MD scheme which might be just as good or better, with about 1/2 of the excess CPU.

In a way, the new scheme is more simple, where the current one is brute force.  There might need to be some adjustment to the scheme,

but my guess is that the quality might be as good as the --xppp=max mode (which is impossibly slow for FA), but the CPU usage will be slightly

slower than for --fz without any args.   Of course, will need to create a slightly faster mode to practically emulate the CPU performance for --fz.

 

Enjoy the release -- the snippets are just finishing up.   PM me if you need anything.

RELEASE:

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

 

SNIPPETS:

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

 

 

 

 

 

Link to comment

Interesting project!

May I ask if there is a place where I can read up on this projects goal? I'm reading this thread, and from what I gather up to now I think I get it;  unravelling compressed releases.

 

Which is highly interesting as there for sure are bound to be many recording that are messed up. 

I don't want to mess up this thread too much, will have a listen to the two snippets tonight.

ISP, glass to Fritz!box 5530, another Fritz!box 5530 for audio only in bridged mode on LPS, cat8.1, Zyxel switch on LPS, Finisar <1475BTL>Solarflare X2522-25G, external wifi AP, AMD 9 16 core, passive cooling ,Aorus Master x570, LPSU with Taiko ATX, 8Gb Apacer RAM, femto SSD on LPS, Pink Faun I2S ultra OCXO on akiko LPS, home grown RJ45 I2S cable, Metrum Adagio DAC3, RCA 70-A and Miyaima Zero for mono, G2 PL519 tube amps. 

Link to comment
10 minutes ago, MarcelNL said:

Interesting project!

May I ask if there is a place where I can read up on this projects goal? I'm reading this thread, and from what I gather up to now I think I get it;  unravelling compressed releases.

 

Which is highly interesting as there for sure are bound to be many recording that are messed up. 

I don't want to mess up this thread too much, will have a listen to the two snippets tonight.

Heh -- people say that I have messed up the thread myself -- the owner of the project 🙂

You are correct about the term 'unravelling', because the effect isn't quite 'expansion', even though it does 'expansion' as part of the process.

 

1)  The project is implemented as a C++ program that runs on Linux or Windows, and is command line and very primitive installation.   When running in a different mode, the same program is used as a DolbyA decoder by professionals.  (Probably the best possible DolbyA decoder), but that is NOT what the program is used for by consumers.  I takes .wav files in and puts out .wav files.  Uses most common sample rates, and accepts 16bit, 24bit and FP.  It outputs 24bit and FP.   It will work with RF64 and utilizes/generates BEXT records.  Other metadata is respected or generated.   The program will do a full RF64 FP professional album, or works fine with individual songs on a CD.   It does NOT do .flac or other compressed formats, I have shell scripts for full album decodes, and use SoX for quick test runs.

 

2)  The best way to describe what the program does is by two examples:

A Brubeck piece:

RAW from a 176k/24 consumer copy (downsampled for demo):

https://www.dropbox.com/s/3c6nm2w4a5r4pbc/01-Blue Rondo a la Turk-RAW.flac?dl=0

DECODED from exactly the same source:

https://www.dropbox.com/s/luahrp6qyjbyo52/01-Blue Rondo a la Turk-DEC.flac?dl=0

 

An ABBA piece:

RAW from CD:

https://www.dropbox.com/s/4889seke7hjnpxs/02 - Take A Chance On Me-RAW.flac?dl=0

DECODED from exactly the same source/version/etc:

https://www.dropbox.com/s/znjerng1aq0ouu6/02 - Take A Chance On Me-DEC-V2.2.4D.flac?dl=0

 

3)  There have been bugs, and as you can probably guesstimate, it is not simple to do what the program does, or someone would have written this a long time ago.

The bugs have been chipped away  until, right now, is probably as good as it can reasonably be.

 

4)  As you can tell in the two examples, the program doesn't really sound like an expander, but it truly is.  It expands at the very low levels, and is so darned fast that it reaches down and re-organizes the signal so that it is temporally and level-wise correct.   This is why your term'unravelling' is a very accurate one.   I have burnt-out a lot of generations of users while thinking that the decoder was 'perfect', then finding out that it isn't.  As time went on, I found out that my hearing wasn't reliable -- so this last burst of development has been painful.  (The attack/release times are in the 2msec to 8msec attack and 40msec (yes, really) to 160msec release.)  These are true RC attack release as they are calculated to be RC time constants rather than just follow one.  This undoes EXACTLY the encoding methodology that garbages-up our favorite recordings.

 

5) YES, the decoder really IS usable, and probably close to perfect -- FINALLY!!   The biggest gotcha -- no GUI.

 

The program is free to use for FA (the consumer stuff) users, and mostly free for DA (for pros) users.  The program is very slow, but in the lower quality modes (still better than what a DolbyA could do in the same situation), can run faster than realtime on a moderately modern 4 core AVX2 CPU (Ryzen, i4770 or newer desktop.)   I use a 10core X processor and can get realtime perf in the highest quality modes.   The program will grab as many cores as your CPU has...   How much CPU does it take?  How much do you have... :-).

 

The program is also now almost VERY easy to use, once you get over the command line hurdle.

Used to be, because I didn't know all of the 'secret sauce', the program required a LOT of tweaking -- now, not even the calibration

levels normally need to be changed.  It works ALMOST out of the box.

 

Here are some more A/B demos, and if you really want to use the program, I'll help you get started.  Isn't too hard once you get the knack.

(RAW is from CD or digital distribution, DEC has been decoded):

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

 

The program is at (and as I wrote above, primitive to use and set-up, more for a computer person than an audio person):

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

(V2.2.4E)

 

 

 

 

 

Link to comment
37 minutes ago, lucretius said:

 

The usage document, "StartUsage-V2.2.3E.pdf", appears to be from an earlier version (i.e. not V22.4E).  Is this correct?

Thanks for the heads-up.   I misnamed the filename -- even made a mistake on the title, but fixed both.

If you do have any suggests -- the door is still open.   There are some posible changes that stay within the rules, but the new rules seem to be much

better than the previous.  (There are still some arbitrary things, and always the possibility of a typeo.)

 

I am currently a little worried about the

bass -- but my hearing is so untrustworthy, I must assume that my previous judgement is correct.  (Here is an example - the 10dB compensation after decoding, it is possible

that needs to be done differently or with a higher Q than just 0.8409.   If I increase the Q to 1.0, the amount of bass will increase without actually increasing the maximum

amount of bass.)   Instead of trusting myself, I just chose a 'vanilla' setting.  If you think there is a need for a slight nudge in the bass -- it is easy to do, and still 'follow the rules'  (Q=1 and Q=0.8409 are within the 'rules'.    Q=0.707 or Q=1.414 are NOT.)

 

ADD-ON:  As far as I am concerned, the decoder IS done, but I accept changing the bass compensation Q from 0.8409 to 1.0 as a user requested bugfix.  We might run into a few of them, but the code IS finished, and the Q decision that I made was 'conservative'.  In this kind of circumstance, Q=0.8409, Q=1.0 or Q=1.19 are possibly correct.   I did not want to over-boost the bass (where the higher Q starts the bass compensation earlier below 75Hz) -- so I decided that it is more likely to get complaints about 'thinness', then adjust upwards.  Too much bass is REALLY evil as we all know.

 

 

About the bass -- the numbers are all common sense, and reasonable reverse engineering -- NEVER doing any tweaking again -- the old LF code is good enough for the rest of my life :).

 

Thanks again!!!

Here it is, just in case...

StartUsage-V2.2.4E.pdf

Link to comment
1 hour ago, John Dyson said:

One thing that has REALLY bothered me is the lack of a public version of a general purpose bilinear S to Z converter.

 

Speaking as someone considerably far outside your field.  There have been a few times you sent me digging to get even a small sense of what you are idly picking at until it's bothered you enough to do something with.  

 

This might be of help to a few others who felt the lack of math in their day needed to be rectified.

 

50 minutes ago, John Dyson said:

I have burnt-out a lot of generations of users while thinking that the decoder was 'perfect', then finding out that it isn't. 

 

Generations might be foreshadowing and a bit pompous, Mr. John "womb shudder" Dyson.  x-D  

 

As for the second part.  Numerous of us have asked you to effectively... upwards 10 versions being uploaded in the last 48 hours...    

 

 

On 3/30/2021 at 3:11 AM, mocenigo said:

If you are indeed the John Dyson the developed parts of FreeBSD, you should know that this is not the way to develop software. You are not giving yourself enough time to think at all the variables and see how they interact.

 

Link to comment

the difference in how the material presents itself is very interesting, rather intriguing.....I'll have to listen more, as on my current setup (which is mono, errr one channel, due to space restrictions in the house we currently live in) there appears to be lots of merit (the middle and higher frequencies sound so much more natural) yet there is something that might indicate a phase issue (which could mean that phase was messed up tp begin with or got mangled in the process) 

ISP, glass to Fritz!box 5530, another Fritz!box 5530 for audio only in bridged mode on LPS, cat8.1, Zyxel switch on LPS, Finisar <1475BTL>Solarflare X2522-25G, external wifi AP, AMD 9 16 core, passive cooling ,Aorus Master x570, LPSU with Taiko ATX, 8Gb Apacer RAM, femto SSD on LPS, Pink Faun I2S ultra OCXO on akiko LPS, home grown RJ45 I2S cable, Metrum Adagio DAC3, RCA 70-A and Miyaima Zero for mono, G2 PL519 tube amps. 

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...