'FeralA' decoder -- free-to-use

[bogi]

3 hours ago, John Dyson said:

da-avx   --infile=in.wav --overwrite --outfile=out.wav --tone=-50  --fcs="6,auto,fcf"  --pi1k=1 --pi=v4 --pi=hf5

 

I'm just trying ... didn't listen yet.
Small correction: --input and --output instead of --infile and --outfile

[bogi]

4 hours ago, John Dyson said:

Well, once you are used to it, probably can make the correct choice in under 2-3minutes -- probably 20 seconds.

 

Hi John, I don't understand how you are doing this. Processing of few minutes long WAV file takes minutes. Then I try it. Then I change some parameter and I need again wait minutes for the processing to finish. Are you running in advance some batch to produce results with more parameters so then you don't need to wait for processing? Or are you working with a shortened track say to 20 seconds to do things faster? Or maybe are you processing it directly to an output audio device instead of writing to WAV? Maybe I didn't understand something basic what was already mentioned in this thread.

[bogi]

I found the -play switch ...
The improvement in sound is much higher than I thought. It really helps!

[John Dyson]

6 hours ago, bogi said:

I found the -play switch ...
The improvement in sound is much higher than I thought. It really helps!

Yea -- Id' be insane by now without real-time play!!!

 

On Linux, you can just pipe the audio through the decoder to the SoX or other 'play' command.

On Linux and Windows, you can use the --play command or the --splay command.   Use --splay if you prefer to use SoX based stuff, or --play if otherwise, where the adjunct program 'aoplay' is called, then directly connects to whatever audio system your computer has.

 

Yep -- without realtime play, the decoder project would have died a LONG LONG time ago!!! :-).

 

Please look for the V1.6.9A version -- I just uploaded it,  I am not officially releasing it yet (it is being tested by the small tester group), but you might see some good things about it.   Since I mentioned it -- I guess I am releasing it :-).    I don't have any release information written yet, but suffice to say, vast improvement in the detector mechanism (using better Window functions on the Hilbert detectors), and given that improvement (less wobble), then I could make the HF0/HF1 cancellation more temporally correct -- therefore making much more realistic sound.

 

The DA part of the decoder has been 99% better than a true DolbyA for a long time ,but there were always 'differences'.   The resulting sound appears to have no obvious impairments AT ALL against DolbyA, and is definitely more clean sounding as expected.   This V1.6.9A is a major improvement in the DA section, which is 100% critical for the rest of the decoder.

 

I won't be passing the V1.6.9A to the pro users for a few days, just to make sure all is okay!!!

I'll do some kind of 'release notes' some time tomorrow.

 

John

 

[John Dyson]

Today, or this weekend, I'll be working on the docs for the latest (hopefully close-to-final) version of the DA decoder.

This version, V1.6.9A is definitely very good, and I'll hopefully have a release notes ready by tonight.   The usage docs are the same as the previous release, but a more complete document will also be coming in 'days' not 'weeks'.

 

Probably, later on today, will also prepare some snippets for public reivew, from test decodes being done over the last few days.

 

John

 

[John Dyson]

I am ready to make the first TRULY easy to use, fully functional release.

 

The results are ending up with  a perfect reproduction of a piano in classical, and very clean results in most pop.   The only odd recordings are ABBA -- I did finally figure out that to get a more 'real' sound, more post decoding EQ is needed.   I really WISH that I could publically post the full results that are coming out...

 

The new, V1.6.9 series of release will be ready later on today.   I have some final tests to do, but it is looking like the only things that will be needed in the future are usability features.   The Usage guide is still all that I have for docs (been very weak after vaccine...)

 

The commands are now greatly simplified, and the decoding/EQ settings look like this (other than the input/output file specs):

 

For typical POP:

--tone=-50  --fcs="6,auto,fcf" --pi=hfN --pi=vM --pi1k=1

 

For typical classical:

--tone=-50 --fcs="6,auto,fce" --pi1k=1 --fw=classical

--tone=-60 --fcs="6,auto,fce" --pi1k=1 --fw=classical

 

It is possible that some classical recordings require settings close to the pop settings.   Normally classical decoding is MUCH simpler, because they tend to do less to the recordings.  All recordings appear to need the --pi1k=1 specification.

 

The numbers 'N' and 'M in the POP recordings are usually N=3, M=5, but others are possible (N=0->5, M=0->6).   There are also some +,* or - modifiers on the 'hf' or 'v' EQ, but those are very seldom needed.  The --tone= settings are usually -50, -46, -60 (mostly classical) or -54.5.   By far, most often the --tone= is usually -50.   When I am working on decoding material, I can easily forget the EQ for 'M' and 'N', but remember that 'bigger numbers mean more HF'.

 

Using the decoder  is about as simple as it can get, and I am getting amazingly good results.

Perfect piano (snippet1), that is something that is missing on most consumer recordings nowadays...

 

https://www.dropbox.com/s/qtunbpnfc9tku0y/01 - Rhapsody in Blue-snippet.flac?dl=0

https://www.dropbox.com/s/cyj8kd8h89t15v4/01 - Rhapsody in Blue-snippet1.flac?dl=0

 

 

Give me +8Hrs from now to get the release out.  I don't want to waste any more peoples time.

John

 

 

[John Dyson]

New version -- FINALLY -- it is pretty much done.

Documentation and minor usability fixes.   Might add some EQ options (e.g. ABBA specific EQ :-)).

 

Here is the release, you want the V1.6.9D version.  Easy to use, childs-play for those who are used to command line, but GUI users will have troubles.  I admit that to be a problem.   If you want to get rid of the cr*ppy sound on most CDs -- this is it.  The distributors will call it a piece of software from h*ll, and shows the terrible damage done to people's CDs that they spent REAL money on.  There WILL be push back, but mostly from those with 100% buy in to the bad sound.   This will recover the pre-damage quality most of the time (by far), and actually works EASIER on classical recordings than on POP!!!

 

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

 

The program is fully functional, had worked on every FA recording that I have tried (well, some do require some serious EQ differences -- the ABBA catalog, for example.)

 

John

 

Usage-V1.6.9D.pdf Notes-V1.6.9D.txt

[bogi]

Hi John, thanks for simplifying the usage! I would like to understand, if the FA decoder does some analysis on input source file and adapts its processing based also on input content, or if the functionality is influenced only by the command line parameters.

[John Dyson]

15 hours ago, bogi said:

Hi John, thanks for simplifying the usage! I would like to understand, if the FA decoder does some analysis on input source file and adapts its processing based also on input content, or if the functionality is influenced only by the command line parameters.

It doesn't dynamically process the recording, but instead creates EQ in the right places instead of requiring the user to choose all of the EQ at every step.

The problem was, even though the decoding was simplified over the recent months, it has been still too intricate for me to explain how it works -- EVEN ONCE I FULLY FIGURED IT OUT.   Frankly, it was too intricate for even me to reliably use.   It is NOW easy to use for anyone with reasonable patience.

 

*  Decoding is super reliable, and the SAME decoding command for most 'classical' and the same for most 'pop' -- just change the '--tone=' value.

The decoding FA initiator for 'classical' is 'fce', for 'pop' is 'fcf'.

*  The difficult part now is post-decoding EQ, but 'decoding' has always been  the slow part.   EQ was much quicker, so iterations are much quicker.

 

Before, I was also getting caught-up in ad-hoc decoding just like everyone else.   This has been too error prone, and also I needed to impose more structure and make it more difficult to make an 'artful' mistake.   There is a certain, and very important, discipline, with two different major EQs for *decoding*:

 

1) beginning of each layer

2) beginning of each increasing sequence  * definiing sequence for 6 layers as -50,-40,-30,-20 as first sequence, then 2nd is -60,-50.

 

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

(ALL COMMAND: examples below, I have skipped the da-avx and input/output and 'info' stuff)

 

Originally, once I figured out the correct, reliable sequence,  the steps for each layer shouldn't be the same.  But, the problem for EVERYONE, including me, that there was a *discipline* to the EQ -- it was too easy to break the discipline.  The way that the decoder works 'automatically' now, if you use 'fcf' and 6 layers:

 

<start-seq-EQ>  <fcf-EQ>  <layer0> <fcf-EQ> <layer1> <fcf-EQ> <layer2> <fcf-EQ> <layer3> <start-seq-EQ> <fcf-EQ> <layer4> <fcf-EQ> <layer5>

command:  --tone=-50  --fcs="6,auto,fcf"

 

The non-automatic (original  way):

<fcd-EQ> <layer0> <fcf-EQ> <layer1> <fcf-EQ> <layer2> <fcf-EQ> <layer3>  <fcd-EQ> <layer4> <fcd-EQ> <layer5>

command: --fcs="1,-50,fcd" --fcs="3,-40,fcf" -fcs="1,-60,fcd" --fcs="1,-50,fcf"

(note the long command for a correct non-automatic decode.   It is also very easy to be seduced into violating the protocol, thereby changing the correct 'fcf' or 'fcd')

 

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

Looking above, for CORRECT decoding, the number of --fcs commands (4) in order to correctly implement 6 layers was still too complicated.  If I was also making errors, then everyone else would make errors also.

 

I figured that it was worthwhile to add the automation into the program.   The program was already structured so that adding the sequencing was bordering on trivial, and there would be incessant 'poor decodes' without the improvements, so it was best to add the automation.

 

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

PROPER DECODING (99%) of the time, well -- sort-of

 

1) <decoding the file *directly*>   2) <post-decoding-EQ>

 

* NO EXTRA EQ BEFORE DECODING -- unless the file is deficient (not needed 99% of the time.)

 

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

 

1st step:  do the new, easier to use '--fcs' command mode

2nd step (either in the same program run, or as an --equalizer pass):  Do the necessary --pi 1st order EQ commands.

 

Just decoding almost any pop recording is done like this now:

 

command:  --tone=<correct-tone-value>  --fcs="6,auto,fcf"

 

Equalization can be done after the decoding command or as a separate pass:

 

command:  --pi1k=1 --pi=v3 --pi=hf3

The --pi1k=1 is almost ALWAYS needed.

--pi=v3 is optional, but needed most of the time, and 'v3' might be 'v0' though 'v5'

--pi=hf3 is optional, but nedeed most of the time, and 'hf3' might be 'hf0' through 'hf6'

 

There are exceptional cases, where the recordings need slightly different EQ shape.   If the sound is 'blaring', like the vocals are way  too loud, but cannot EQ it other ways, then try '-hfX' (add a '-' to before the 'hf') like --pi=-hf1.

 

Also, the vocal might sound buried, like it is 'suppressed' somehow.   This is where you might want to try adding '+' or '*' to the 'vX' type value.   So, to bring the vocal more forward without making it 'loud', then do something like --pi=*v2

 

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

 

All of this post-decoding EQ is not needed as often with 'classical' recordings for some reasons.   Classical (and very few POP) recordings are done with a slightly different stereo image.   This can be controlled by the --fw switch.   The currently available (and forever) options are:

 

--fw=classical (most classical)

--fw=mix (Carly Simons recordings need this)

--fw=pop (most pop, default.)

 

Also, some recordings were done with a narrowing or widening of the stereo image.   This is done because FA distorts the image and actually makes it vibrate with the gain control.   Anyway, you can widen the stereo image by adding:  --wof=1.19, or narrow the stereo image by --wof=0.8409.

 

The stereo image stuff all appears to be based on '2', 'sqrt(2)' and 'sqrt(sqrt(2))'.   1.19 is sqrt(sqrt(2)).   0.8409 is 1/sqrt(sqrt(2))).   The 'mix' stereo image uses 1.414 and 0.707 in the mid/side calculations, and pop uses 2 and 0.50.

 

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

I'll be doing a more complete manual soon, but I DO believe that this is as simple as it can be.   In the past, I didn't really know all of the EQ that was used, even whether there was 1st order or 2nd order.   This took very very persistent testing -- irritating a lot of users, but the learning curve on this kind of stuff is slow.

 

The only changes right now are related to micro level stuff -- I am making Christmas presents right now, and totally satisifed with the decoder.  I have promised my sister a memory stick of recordings for 2yrs now, and finally I am making it.   The decoder IS FINISHED.

 

John

 

[John Dyson]

On 11/12/2020 at 1:08 PM, bogi said:

 

Hi John, I don't understand how you are doing this. Processing of few minutes long WAV file takes minutes. Then I try it. Then I change some parameter and I need again wait minutes for the processing to finish. Are you running in advance some batch to produce results with more parameters so then you don't need to wait for processing? Or are you working with a shortened track say to 20 seconds to do things faster? Or maybe are you processing it directly to an output audio device instead of writing to WAV? Maybe I didn't understand something basic what was already mentioned in this thread.

I meant, that you can do a short decode with the --play or --splay command, avoiding the long wait.  On Linux, you can also pipe the output to the SoX play command.

 

Once you are sure that you got the --tone= correct for a given recording, then just run-off the decodes.   Next, test-run the EQ until you are happy with the sound.   You can do one en-masse superhigh quality --fz decode (I don't recommend that when starting though), and then work on the EQ very quickly later on.   That is how I do decodes now, since I have learned how to figure out the correct --tone value.

 

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

 

So, you can do this, once you have found the correct parameters -- here is a concrete example:

 

da-avx --input=in.wav --overwrite --output=rawdecode.wav --info=2 --tone=-50 --fcs="6,auto,fcf"

then, you can do this to do the eq:

da-avx --input=rawdecode.wav --overwrite --output=final.wav --info=2 --equalizer --pi1k=1 --pi=v3 --pi=hf3

do both steps above, all in one command:

da-avx --input=in.wav --overwrite --output=rawdecode.wav --info=2 --tone=-50 --fcs="6,auto,fcf" --pi1k=1 --pi=v3 --pi=hf3 --play

 

if you want to do a full decode & EQ and do realtime play:

da-avx --input=in.wav  --info=2 --tone=-50 --fcs="6,auto,fcf" --pi1k=1 --pi=v3 --pi=hf3 --play

 

---

 

*  For pop recordings, now, all you have to do is to choose the number of layers (4 or 6 is a good start), and the --tone=value.   I haven't seen any variance from the 'fcf' initiator.   So, the command:   --tone=<tone-you-find-is-good>   --fcs="4,auto,fcf"...    This command doesn't have lots of choices, does it?   There are tricks to finding the correct --tone=value, but newer recordings are almost always -50, but sometimes -60 for classical or -54.5...    Older recordings are often -46 or even --44.5.

 

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

For layers, it is all about how much compression that you tolerate.  Most recordings are done to at least 6 layers, I am doing the beatles at 6 layers, the Rhaposdy was at 8 layers.   With more layers, there is more compression removed.   Warning:  you can specify more layers to decode than layers of compression in the recording, and that doesn't have any 'tells', but you'll hear that something is wrong.

 

I constrained the 'post decoding EQ' with the --pi=v* and --pi=hf* commands that mistakes will happen less often.

 

SOME recordings might not comply with the EQ that I provided, but if you get it close, then using the '--pix' type EQ can finailize the EQ.   Note that I wrote '--pix' and not '--pif' or just '--pi(freq) type EQ'.   There is a strong reason that '--pix(freq)' --pi=vN and --pi=hfN will be correct more often.   If you include the built-in --pi=v* and --pi=hf* macros, they automatically expand into multiple --pix style EQ.   (--pix means EQ that starts at the specified frequency, like --pix3k starts at 3kHz, and stops at 21.5kHz.)   Pix always stops at 21.5kHz.    The --pif always stops at 60kHz (basically infinity.)

 

John

 

[John Dyson]

2 hours ago, John Dyson said:

I meant, that you can do a short decode with the --play or --splay command, avoiding the long wait.  On Linux, you can also pipe the output to the SoX play command.

 

Once you are sure that you got the --tone= correct for a given recording, then just run-off the decodes.   Next, test-run the EQ until you are happy with the sound.   You can do one en-masse superhigh quality --fz decode (I don't recommend that when starting though), and then work on the EQ very quickly later on.   That is how I do decodes now, since I have learned how to figure out the correct --tone value.

 

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

 

So, you can do this, once you have found the correct parameters -- here is a concrete example:

 

da-avx --input=in.wav --overwrite --output=rawdecode.wav --info=2 --tone=-50 --fcs="6,auto,fcf"

then, you can do this to do the eq:

da-avx --input=rawdecode.wav --overwrite --output=final.wav --info=2 --equalizer --pi1k=1 --pi=v3 --pi=hf3

do both steps above, all in one command:

da-avx --input=in.wav --overwrite --output=rawdecode.wav --info=2 --tone=-50 --fcs="6,auto,fcf" --pi1k=1 --pi=v3 --pi=hf3 --play

 

if you want to do a full decode & EQ and do realtime play:

da-avx --input=in.wav  --info=2 --tone=-50 --fcs="6,auto,fcf" --pi1k=1 --pi=v3 --pi=hf3 --play

 

---

 

*  For pop recordings, now, all you have to do is to choose the number of layers (4 or 6 is a good start), and the --tone=value.   I haven't seen any variance from the 'fcf' initiator.   So, the command:   --tone=<tone-you-find-is-good>   --fcs="4,auto,fcf"...    This command doesn't have lots of choices, does it?   There are tricks to finding the correct --tone=value, but newer recordings are almost always -50, but sometimes -60 for classical or -54.5...    Older recordings are often -46 or even --44.5.

 

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

For layers, it is all about how much compression that you tolerate.  Most recordings are done to at least 6 layers, I am doing the beatles at 6 layers, the Rhaposdy was at 8 layers.   With more layers, there is more compression removed.   Warning:  you can specify more layers to decode than layers of compression in the recording, and that doesn't have any 'tells', but you'll hear that something is wrong.

 

I constrained the 'post decoding EQ' with the --pi=v* and --pi=hf* commands that mistakes will happen less often.

 

SOME recordings might not comply with the EQ that I provided, but if you get it close, then using the '--pix' type EQ can finailize the EQ.   Note that I wrote '--pix' and not '--pif' or just '--pi(freq) type EQ'.   There is a strong reason that '--pix(freq)' --pi=vN and --pi=hfN will be correct more often.   If you include the built-in --pi=v* and --pi=hf* macros, they automatically expand into multiple --pix style EQ.   (--pix means EQ that starts at the specified frequency, like --pix3k starts at 3kHz, and stops at 21.5kHz.)   Pix always stops at 21.5kHz.    The --pif always stops at 60kHz (basically infinity.)

 

John

 

Oh my -- writing all of this stuff is error prone, and so I need to correct a full section of the previous post:

ANOTHER IMPORTANT CLARIFICATION:   I am working on Docs also.  Christmas presents are getting priority, but I am sure that with some docs, using the decoder will be easier -- even for the neophyte.  The big bugaboo is that the program is command-line, but that should be the biggest problem in the near (approx +1.5wks at the longest) future.

 

-----

 

So, you can do this, once you have found the correct parameters -- here is a concrete example:

 

da-avx --input=in.wav --overwrite --output=rawdecode.wav --info=2 --tone=-50 --fcs="6,auto,fcf"

then, you can do this to do the eq:

da-avx --input=rawdecode.wav --overwrite --output=final.wav --info=2 --equalizer --pi1k=1 --pi=v3 --pi=hf3

do both steps above, all in one command:

BAD:  da-avx --input=in.wav --overwrite --output=rawdecode.wav --info=2 --tone=-50 --fcs="6,auto,fcf" --pi1k=1 --pi=v3 --pi=hf3 --play

da-avx --input=in.wav --overwrite --output=final.wav --info=2 --tone=-50 --fcs="6,auto,fcf" --pi1k=1 --pi=v3 --pi=hf3

 

if you want to do a full decode & EQ and do realtime play:

da-avx --input=in.wav  --info=2 --tone=-50 --fcs="6,auto,fcf" --pi1k=1 --pi=v3 --pi=hf3 --play

 

----

 

It is best to write some shell (command) scripts...   Even though decoding is simpler, it is so easy to make mistakes.

If you use SoX and Linux, then it is easier yet to do 'quick' decodes.   I also use the sndfile package for conversions -- my scripts are meticulous about keeping the file metadata..   For me, the metadata is more of a problem than decoding!!!

 

In fact, I write scripts for every album that I am working on.   Once in a while I do quick tests, but depend on command line history and edit previous commands.   I VERY SELDOM write entire command lines anymore, just edit the old ones :-).

 

John

 

[John Dyson]

For those using the 'decoder' -- I am finding a certain characteristic that is 'variable' on some recordings.   Some FA recordings appear to have a rolloff at approx 15kHz (plus or minus), and this rolloff, since it does reach below 12kHz can create an audible problem with the HF0/HF1 cancellation.   This cancellation is very critical...

 

---

At least, on the test material that I have -- the highs for intense material are made more smooth/even sounding if the following is added before the --fcs command:

 

--b15kxxk --b18k22k

 

The above two switches must be used exactly as written.   Don't use --b18kxxk or --b15k22k to substitute.   A substitution will make the cancellation less effective.

---

 

What do these do?   Add two 1st order EQ 'boost':   One is 15k -> 60k.   The other is 18k -> 22k.   Even the slight 18k -> 22k boost is important.  You might find recordings that need one or the other, but several recordings tested so far DO benefit from the two HF boosts above.   (--b switch really DOES mean 'boost'.)

 

John

 

[bogi]

On 10/15/2020 at 5:08 PM, John Dyson said:

Some of the demos were done with 7 layers (-46dB, -36dB, -26dB, -16dB, -56dB, -46dB, -36dB)

Hi John, I am searching for more explanation what the layers mean. Does it mean something like when more tapes are added into the mix and they were encoded by Dolby A or something similar, then that Dolby A of every tape used creates an additional layer?

Could you please explain also the values (-46dB, -36dB, -26dB, -16dB, -56dB, -46dB, -36dB) ... why exactly these and whats the reason of 10dB delta? The answer is probably related to information I found in Wikipedia about Dolby A:

Quote

 

The input signal is split into frequency bands by four filters with 12 dB per octave slopes, with cutoff frequencies (3 dB down points) as follows: low-pass at 80 Hz; band-pass from 80 Hz to 3 kHz; a high-pass from 3 kHz; and another high-pass at 9 kHz. (The stacking of contributions from the two high-pass bands allows greater noise reduction in the upper frequencies.) The compander circuit has a threshold of −40 dB, with a ratio of 2:1 for a compression/expansion of 10 dB. This provides about 10 dB of noise reduction increasing to a possible 15 dB at 15 kHz, according to articles written by Ray Dolby and published by the Audio Engineering Society (October 1967)^[3][4] and Audio (June/July 1968).

 

 

Does it mean something like that with -46dB the tool expands dynamics of the original recording dynamic range interval from -46 to -36dB, creating also quieter tones than -46 dB ? And then it expands the interval <-36, -26> which was not touched by the previous step? Or is my imagination totally wrong? :)

[John Dyson]

11 hours ago, bogi said:

Hi John, I am searching for more explanation what the layers mean. Does it mean something like when more tapes are added into the mix and they were encoded by Dolby A or something similar, then that Dolby A of every tape used creates an additional layer?

Could you please explain also the values (-46dB, -36dB, -26dB, -16dB, -56dB, -46dB, -36dB) ... why exactly these and whats the reason of 10dB delta? The answer is probably related to information I found in Wikipedia about Dolby A:

 

Does it mean something like that with -46dB the tool expands dynamics of the original recording dynamic range interval from -46 to -36dB, creating also quieter tones than -46 dB ? And then it expands the interval <-36, -26> which was not touched by the previous step? Or is my imagination totally wrong? :)

 

'layers' are my terminology.   It appears that DolbyA units were used for each 10dB range of signal level, each DolbyA unit is a 'layer'.   In some cases, at lower signal  levels, they doubled-up the compression, therefore the calibration #'s overlap after the 4th 'layer'.   It seems like most recordings are compressed to 4,6 or 8 layers (perhaps more, perhaps less.)   Interestingly, using too few layers in compression can sound worse and have more artifacts than using sufficient numbers of layers.   Wider dynamic range material (e.g. orchestral stuff) appears to be compressed to 8 layers in some cases, but it *appears* that POP is often compressed to 6 layers.

 

* DolbyA style compression, where a DolbyA unit is used as these stacked compressors works relatively well because of the kind of attack/release curve that it has.   The attack/release on DolbyA is mind-bogglingly wierd, but GENIUS.   This stacking would NOT work with normal compressors/expanders.

 

* This 'scrambled' form of compression isn't very amenable to being expanded by a normal expander (maybe, you could get 10dB of reasonable expansion -- just maybe.

 

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

 

What are the calibration numbers?   The best way to describe it is that master tapes are often approx -13dB in the DHNRDS calibration level terminology.   So, it makes sense if the 'compression' calibration is some value less than -13dB.   When specifying -13dB, the actual compression of high frequencies stops at some level below -13dB (I cannot remember exact numbers, but I have them in my data), but when specifying perhaps -40dB, then the actual compression threshold is in a 20dB range well below -40dB.    DOLBYA COMPRESSES UPWARDS (so, a -30dB signal might be -25dB level after compression), but DOLBYA EXPANDS (decodes) downwards, so a -25dB input signal might become -30dB.    At levels of 10dB or higher (at least), DolbyA doesn't touch the signal AT ALL.

 

So, when they encode the pop material, and since DolbyA units only do 10dB of approx 2:1 compression over a limited range of levels, they stack the DolbyA units to gain more compression.   The kind of compression created is NOT easily undone with normal expanders, and also the compression produces a consistent kind of sound without needing to explictly master each recording.

 

Each 'layer' is a DolbyA unit -- the general diagram is like this (I cannot draw well, so I'll try ascii-art), a 'typical' decode starting at -50dB (could be -46 or -54.5 or even -60dB)

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

DECODING (like the DHNRDS FA decoder):

 

CD INPUT ->

SEQ0 -> DEQ0 -> (L0) -50dB decode -> DEQ1 -> (L1) -40dB decode -> DEQ2 -> (L2) -30dB decode -> DEQ3  -> (L3) -20dB decode ->

SEQ1 -> DEQ4 -> (L4) -60dB decode -> DEQ5 -> (L5) -50dB decode -> Post-decoding EQ -> BETTER AUDIO OUTPUT

 

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

 

First sequence (SEQ0) starts at -50dB up to -20dB (4 layers)

Second sequence (SEQ1) starts at -60dB up to -50dB (2 layers)

 

Each layer (e.g. L0, L1, ...) are effectively a DolbyA decode with the threshold at specified dB level.

Each group of increasing calibration levels is a 'SEQUENCE' (e.g. SEQ0 or SEQ1).

 

Before each sequence (SEQ0, SEQ1), there is a special EQ -- SEQ.

Before each layer (L0 -> L5), there is another special EQ -- DEQ.

 

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

 

After a lot of pain and research, I found that the 'SEQ*' and 'DEQ*'  are pretty much consistent from recording to recording*.   That would be the 'fcf' style of EQ for most POP or 'fce' style of EQ for most classical.   The Usage doc describes pretty much what fcf and fce mean, but I haven't fully documented the 'SEQ*' yet, it is simple, but also important.

 

* earlier, I had created a crazed myriad of EQ schemes -- I didin't realize how insane it was -- but without specs, all I could do is to do a long, painful subjective measurement/correction/measurement/correction -- until almost going crazy!!!

 

Nowadays, the 'automatic' mode automatically adds-in the 'SEQ*' sequence EQ along with the decoding EQ.   This eliminates a lot of mistakes.

 

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

 

Nowadays, the difficult part is NOT the decoding. the 'difficult' part is the post-decoding EQ -- with decoding, given you are decoding 'pop', then you most often need 'fcf' style decoding.   So, most of what you must decide is the # of layers that you want, and the calibration.   Sometimes you have to worry about the stereo image 'the --fw' type of switch.

 

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

Doing 'decoding' is slow, especially the high quality modes, but 'post-decoding EQ' is fairly fast....   What I do (and am doing right now) is:

 

1)  'Decode' a whole album into a bunch of raw, decoded .wav files.

2)  After ffiguring out hte post decoding-EQ, then EQ the whole album, producing the final .wav or .flac files.

 

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

 

 

 

John

 

 

[John Dyson]

Very important suggestion -- as I am currently making Christmas presents, I have really learned how to do bulk decoding.

FIRST, read the MEGA HINT below, then read the text.   The MEGA HINT will give you a good idea about where I am headed with this little note!!!

 

Basically -- save the post-decoding EQ for last.   The raw 'decoding' is now relatively simple, but TIME CONSUMING.   Don't burden the challenging, but quick POST DECODING EQ, with the slow decoding also.   When doing mass decoding of album(s) it might be wise to do the deocoding & EQ in two separate steps.

 

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

 

For POP recordings, you can be almost 100% sure that the FA initiator is 'fcf'

You'll have to be prepared to try -50, -46, -54.5, -56 and -60dB for the calibration level.

Plan on trying 4 layers, and then perhaps 6 layers to see if the sound gets better.

 

How do you know that you have good decoding without checking the post-decoding EQ at the same time?

 

All I can suggest is to start with post-decoding EQ at something like --pi=v3 --pi=hf3 --pi=1k  while doing realtime play, given the suggest settings above...   So, try this for a first-go at it:

 

da-avx --input=in.wav --info=2 --tone=-50 --fcs="4,auto,fcf" --pi=1k --pi=v3 --pi=hf3 --play

(see how this sounds)

NOTE: this is much quicker/easier when using SoX in conjunction with the decoder, but this might not be an option on a given windows box.

 

Listen for decoding artifacts.   If the sound is too shallow, then try --46.  If the low levels appear to 'disappear', then try -54.5dB.   Once you know that the calibration is close to correct, then try tweaking the --pi=v3 and --pi=hf3.   I don't have brilliant suggestions, but if you want to 'darken' the sound, because it has too much super HF, then try --pi=hf4 or --pi=hf5.   If you need to brighten the sound because the super highs are dead, then try --pi=hf2 or --pi=hf1 or --pi=hf0.

 

For the vocals, if they are too strong, then maybe try --pi=v1 or --pi=v0.   If they don't have enough brightness, then maybe try --pi=v4.   If the vocals don't have enough body, then maybe try --pi=*v4.

 

Once you have a good idea about the post-decoding EQ with all of the --pi commands, then go back to the calibration, and listen for artifacts.   Retry the settings again, but when you are done with this last iteration, then all is good.

 

As long as a CD hasn't been normalized, you can trust that the calibration numbers are almost always: --50, -46, -44.5, -54.5, -56, -60.    I haven't run into non-normalized materials that do not have a normal calibration level.

 

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

 

MEGA HINT:   Since decoding is now easy, but the post decoding EQ is affected by subjective effects, I strongly suggest decoding (but not final EQ) a whole album, ONCE YOU HAVE DETERMINED A GOOD CALIBRATION and #layers per the notes above.

 

AFTER JUST DECODING ONLY without post-decoding EQ:  You then have the option of QUICKLY testing with various post-decoding EQ values.   You can then retry the post-decoding EQ during various moods and times of day -- better chance of zeroing in on the best sound qualities.

 

John

 

 

 

[John Dyson]

Apparently have solved the sibilance issue that creeps up from time to time.   I'll add that to the library of information in the near future.   It is a matter of careful EQ and proper calibration level.   Once I realized the needed corrections, I haven't needed to use the dynamic (or static) anti-sibilance notches available in the program.

This probably was most egregious on old pop material like Simon & Garfunkel, Carpenters and one or two Beatles albums.   Sibilance is also weakly manifested on some Olivia material.

 

 

Right now, I am doing massive decodes (but not post-decoding EQ) for much of my library.   Decoding itself is almost trivial.   The post decoding EQ is a little more challenging, and I intend to take notes when I step through each album.   I often make mistakes in the EQ, so I don't want to burden the EQ with the more time consuming decoding.   I already do have prospective post-decoding-EQ choices, because it is iterative with the now limited decoding command set, but there is still room for corrections, fixing mistakes, etc.

 

Then, when I do the final EQ steps, my new procedure is to wait for a day or so after an attempt & double check.   I'll plan to do that several times on each album.  I expect my learning for the EQ procedures will be helpful.

 

Even though I have made incorrect claims in the past -- the ABBA results have gone through the multi-day check already, and they DID require some corrections.   I think that trying to do the EQ open-ended without double checking a day later is frought with error.

 

Important good news:   Every time that I deviate from the built-in post-decoding EQ, the results end up with problems.   This recently happened on some ABBA decode attempts.   I had deviated, initially thinking that they sound nice and bright -- yea, bright like hell.   For me, it is important to avoid demoing 'quickie' test results.

 

*  This basically says that the post-decoding command set is sufficient for most purposes.

 

Gotta stay with the --pi=vN (optional) --pi=hfM (optional)  --pi=hfcP (optional).   Anything outside of those post-decoding-EQ  built-ins (which I chose very carefully) is very likely gonna give you troubles.

 

John

 

 

[John Dyson]

In order to STRONGLY demonstrate the audio dystopia that we already live in -- I found some Dave Brubeck, which is a relatively clean natural recording.   The HDTracks FA version sucks badly.   I wish I had a stereo R2R tape version of 'Take Five' to demonstrate, but this cleaned-up Take Five makes the HDtracks direct version sound HORRID.

 

This recording is a part of the ongoing Christmas present project, but should be ready some time today.   (The 10900X machine is hopefully coming in a few days, but right now I am using a fairly slow machine.)   The speed has been so irritating that I just did a 10% speed improvement (better implementation and more accurate version of the Hilbert transform.)

 

John

 

[John Dyson]

 

This comparison is NO JOKE, and much more obvious on this kind of material even than on POP.

 

Here is the example about how dead sounding that EVEN the normal HDtracks release sounds.   It is NOT their fault, but they are also stuck with the poor quality.

MQA is a problem, but the persistent problem of FA distributions is MUCH MUCH worse when it comes to quality.   There are other aspects of MQA that make it a bad thing.

 

The decoded version is made FROM the HDtracks release  -- the only problem that I might not be able to detect is proper EQ.

How can people even listen to the muffled recordings that are being sold nowadays?

03-Take Five-HDtracks-snippet-48k.flac 03-Take Five-DECODEDC-snippetA-48k.flac

[KeenObserver]

Yes john, you have feral a decoder.

[Skip Pack]

Hello John,

 

Thanks for the latest version, it looks very promising.

 

I have successfully decoded (with no eq) two files using five different calibration levels and 4, 6, and eight passes, all using da-win, as I must. When I try post equalization I get the following:

_______________________________________
PS C:\Users\Skip_Active\Music_Processing\working\BBoys\Surf's Up\4EQ> da-win --input=in.wav --output=out.wav --info=1 --equalizer --pi=1k --pi=v3 --pi=hf3
da-win : PI switch help information:
At line:1 char:1
+ da-win --input=in.wav --output=out.wav --info=1 --equalizer --pi=1k - ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (PI switch help information::String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError . . . . 

__________________________________________

 

With no ourput.

 

The file 'in.wav' plays fine. Any suggestions?

 

Skip

 

 

[sandyk]

John

 Wasn't the original from HDT 24/88.2 and at a different (higher) volume level ?

 

Alex

[bogi]

18 hours ago, Skip Pack said:

Any suggestions?

There is typo in the example, substitute --pi=1k -> --pi1k=1

See the Usage guide page 17

John suggests to use it in most cases. In my case it made my recording too dark, so I omitted it.

[jabbr]

31 minutes ago, bogi said:

John suggests to use it in most cases. In my case it made my recording too dark, so I omitted it.

John prefers less HF content than I do i.e. "darker' so YMMV.  I find that too many layers or too high tone numbers seem to remove the "sparkle" which can be part of a recording so try --tone=-60 or -70 for example, or fewer layers

[Skip Pack]

Thank you Bogi! that nailed it. Onward with my (i x J x k) exploration. 

[John Dyson]

3 hours ago, bogi said:

There is typo in the example, substitute --pi=1k -> --pi1k=1

See the Usage guide page 17

John suggests to use it in most cases. In my case it made my recording too dark, so I omitted it.

Thanks for the feedback...   I have a new copy of Brubeck also, but have no time for snippets.   PM me if you'd like the location of the album, I have corrected the stereo image, calibration, EQ problem and now got dead-on cymbals and piano.   Doing the most massive botch effort -- I mean decoding -- effort for Xmas...  :-)  Will be tied up until approx Wednesday (25Nov.)   Might drop in on AS for quick visit.  Will look for PMs.

 

* I am not reading anything except the FeralA group and PMs for now.  Very busy, but willing to help on specific items.

 

There are also minor (but not changing any previous behavior at all) improvements.   I have added --pi375.

The new --pi=hfN and --pi=vM and --pi=hfcP  are all solid.   They appear to cover 99% of the needed HF EQ (if needed.)   The LF EQ is adequately covered now with --pi375, --pi500, --pi750, --pi1k.   I added both + and - back in for the LF EQ.  (In the new release, you can now say --pi1k=-1 again -- there was a bug that I couldn't fix, but all is good in the next release.)

 

One caveat -- almost all non-classical recordings need --pi1k=1...   Some of my previous mistakes were based on decoding as if --pi1k=1 wasn't needed, which caused some problems with the dynamics.   If doing the complete LF EQ, you can end up with too much super low bass.  Richard wanted for the DA mode decoder to produce +3dB greater signal at 20Hz than a true DolbyA.  He had his reasons, but this means that in FA mode, there WILL be strong super-low bass.  (I believe that the +3dB is correct, and was designed in to DolbyA to handle tape-bumps, but the DHNRDS has no such rolloff.)

 

For all of my efforts, I am using all standard commands -- Brubeck is no exception.  If the results benefit from additions, then they will be added into the next release.

 

John