'FeralA' decoder -- free-to-use

[jabbr]

On 5/3/2020 at 8:04 PM, John Dyson said:

However, questions like this -- are great to discuss in the forum here!!!

 

--fb=b  --fd --tone=-13.76 --xpp  --wof=0.8409

 

Help me here: -fb=b (or a) is easy to understand, but how do we get --tone=-13.76 exactly, I mean is this different from -13.75? or --wof=0.8409 ... is the 4th decimal point significant, e.g why not 0.85?

 

I am trying to develop a strategy for iterating over the parameter domains ... and as you know each iteration has a good amount of data and requires time, and we have --at least-- three variables

 

Also does the avx version use AVX2? what about AVX512?

[John Dyson]

15 hours ago, jabbr said:

 

Help me here: -fb=b (or a) is easy to understand, but how do we get --tone=-13.76 exactly, I mean is this different from -13.75? or --wof=0.8409 ... is the 4th decimal point significant, e.g why not 0.85?

 

I am trying to develop a strategy for iterating over the parameter domains ... and as you know each iteration has a good amount of data and requires time, and we have --at least-- three variables

 

Also does the avx version use AVX2? what about AVX512?

When I do a test for calibration, I usually listen around on a given selection (or album) for expansion artifacts.  I iterate around usually starting at -13.475 -- if I hear gross artifacts, I go up by 0.60 (or to a common value like -13.75) and/or go down by 0.60.   I use 0.60 steps as a matter of habit, and also there appear to be distortion/expansion nulls.

 

If I hear minor artifacts, then I dither around at about +-0.025 intervals.   Sometimes 0.025 makes no/little difference and sometimes it is a difference between inferior/perfect decode.   Usually, I don't need to dither much more than +-0.10.  (The 0.60 intervals are useful for some reason.)   Along with the 0.60 intervals, 1.0 intervals are also helpful to try.

 

The usual values (sometimes spot-on) are -12.875, -13.425, -13.475, -13.75, -14.05, -14.35 -> -14.45 , -14.95, -15.05 and also have run into -19.425 and -20.35 on very premium recordings.   BY FAR, the most common is -13.475 (maybe -13.425 to -13.50).   Much of the time, you can just use --13.475 and be done.

 

I listen in 10 second snippets -- not the entire recording.   I can usually zero in on a value for a full test decode in about 5minutes at most.   Sometimes, the resulting test decode results in a problem -- I remember the time-offset of the problem, and go back through a more precise decoding sequence.

 

About --wof, I found that they use intervals based upon powers of 2:

 

0.707 (2^-0.50), 0.8409 (2^-0.25), 0.91 (2^-0.125), 1.0, 1.09 (2^0.125), 1.19 (2^0.25), 1.414 (2^0.50)

The apparently most common values are in bold -- the non-bold values are probably too extreme.  Of course, '1.0' is the same as omitting --wof.   There is a H*LL of a lot more stereo image manipulation going on -- but these are the finishing touches.   It seems like 0.8409 and 1.19 tend to be the most common, but I found that 0.91 works better on ABBA for some reason.   The recent Led Zeppelin decoding required 1.19.  If that exact number wasn't used, the sound was severely wrong -- it was perhaps the most clear example of needing --wof (Widen Output Final.)

The internal stereo image manipulation is mathematically complex, and effectively varies all over the place.

 

------

I understand the difficulty/challenge of automating the test.   I do suggest adding an automatic selection of a snippet also -- listening/decoding entire recordings can take a lot of time, especially in higher quality modes.

 

BTW -- for decoding, the --basic, --normal, --xtra, --xtraplus, --xtraplusplus and (secret) --xtraplusplusplus...   (--xp, --xpp, --xppp), the calibration is 100% identical.   If you are willing to find a calibration/setting at lowest quality/fastest mode '--basic' and then decode finally at a higher quality level -- you'll get the same results.

 

John

 

 

 

[John Dyson]

16 hours ago, jabbr said:

 

Help me here: -fb=b (or a) is easy to understand, but how do we get --tone=-13.76 exactly, I mean is this different from -13.75? or --wof=0.8409 ... is the 4th decimal point significant, e.g why not 0.85?

 

I am trying to develop a strategy for iterating over the parameter domains ... and as you know each iteration has a good amount of data and requires time, and we have --at least-- three variables

 

Also does the avx version use AVX2? what about AVX512?

Follow-up -- forgot to answer 'AVX' version.   The decoder uses the AVX2 instruction set VERY aggressively.  Every operation that simplifies/speeds up the code is used.  I wrote specially crafted inlines for when they won't screw up the already very good/intelligent compiler optimization.   Theoretically, if there was an AVX512 version of the code, and I could test an AVX512 program (that is one reason why I am considering an i10xxxx CPU), the program would actually take advantage of it.  There are some 8-wide double precision floating point operations in the code, which resolve down to two natural 4-wide double precision SIMD operations on an AVX2 machine.   Those two operations could easily become  one, if I told the compiler to use AVX512.  I'd even write some AVX512 specific inline and transcendental primitives.   Such an update might give a 30% speed improvement on an AVX512 machine.

 

About the AVX2, SSE3, etc SIMD instructions...  They are REALLY cool and  enable the decoder to do the anti-MD operation in real-time.  Even some of the anti-IMD operations that would simply take too much CPU to implement.  If you'd look at the program, there are a lot of operations like a simple gain calculation -- looks like this: ' out = in * gain'.  This SINGLE line of code does 8 FP multiplications.  Even more amazing:  out = out + in * gain, which is an accumulator of sorts.   This single line of code obviously does 8 FP multiplications and 8 FP additions, but BOTH of these examples only need 1 instruction (other than reading/writing memory) on AVX2 machines.  If these were double precision (the deocder does a lot of DP math), then would require at least 2 instructions each -- sometimes a few more fast instructions.  The bits need to be moved around in DP operations for the AVX2 SIMD machine, so require more instructions.  But the simple, reorganizing type instructions are SUPER FAST.  (Where the math might SEEM to take 1  cycle, the reorganizing type instructions can actually SEEM to take less than a cycle.)

 

Each of the instructions above, if scheduled correctly, only seem to require 1 or 2 CPU cycles, that is, at 3,000,000,000 cycles per second.   These new CPUs are very fast, and the DHNRDS DA/FA decoder takes LOTS and LOTS and LOTS of CPU.   An original VAX computer from the late 70s the floating point is about 10,000X slower than ONE core in a current intel/AMD box.   Even the fastest VAX might have still been maybe 2,000X slower.

 

In the late/middle 80's, I was doing some research for an early multimedia communications concept at AT&T/AT&T Bell Labs called 'Unitrax' (the design was bad Karma -- all centralized), and we were needing 3B15s CPU/communications complexes to support the effort.  A 3B15 is approx the power of an original VAX...   I kept thinking -- this is too slow, slower than what we need...   Let me try Unix (the same base OS) on a relatively new i386, and low and behold -- it was 2-3X faster than the 3B15 (approx same as VAX.)   It amazed my product managers -- even though intellectually we 'sort of' knew that these new i386 CPUs were reasonably quick -- but the IDEA that they could outperform a VAX was exciting to say the least.

 

Starting with the i386, the intel (and others, including MIPS, even newer ARMs) left the 'big iron' farther and farther behind.  It wasn't too long before 'chips' could outperform original cray-1/cray-2 type machines.  The i486 really clinched it -- showing that the progress wasn't going to stop.  The Pentium types improved further, and finally going to 64 bits allowed these microprocessors to saturate normal programming, then SIMD and multiple cores kept the improvement going.

 

(the P4 was a fiasco, they assumed that they could keep increasing clock rate, but they hit a wall at about 3GHz -- it actually makes sense about the 'wall'.   instead of increasing clock rates, they made the CPUs smarter with wider data and more actual CPUs on an chip.)  The wall happens partially because the power usage goes up by the frequency^2, and other effects start happening also.

 

So much for my off topic diversion :-).

 

John

 

[lucretius]

3 hours ago, John Dyson said:

Theoretically, if there was an AVX512 version of the code, and I could test an AVX512 program (that is one reason why I am considering an i10xxxx CPU), the program would actually take advantage of it.  There are some 8-wide double precision floating point operations in the code, which resolve down to two natural 4-wide double precision SIMD operations on an AVX2 machine.   Those two operations could easily become  one, if I told the compiler to use AVX512.  I'd even write some AVX512 specific inline and transcendental primitives.   Such an update might give a 30% speed improvement on an AVX512 machine.

 

My CPU (Xeon W-2133) was introduced on August 29, 2017 and it has AVX512.  So it's not just some of the new i10xxxx CPUs that have it.  And just think about all the DAWs that have AVX512!

 

 

 

[John Dyson]

15 minutes ago, lucretius said:

 

My CPU (Xeon W-2133) was introduced on August 29, 2017 and it has AVX512.  So it's not just some of the new i10xxxx CPUs that have it.  And just think about all the DAWs that have AVX512!

 

 

 

Maybe I'll put together the extra money to get AVX512 -- it is just that it has to be a cost benefit tradeoff for me.  For something like new code on AVX512, I have to test it -- new code has to be written to take full advantage.  Perhaps 90% of the time, my tricky assembly code iis correct the first time --- it is the 10% of the time that I worry about.  I don't trust the compiler even for the automatic advantage that it gives.  (My vector package will do most of the work by itself, but there are a few inline asms and some upgrades for the transcendental package needed.)

 

I will evaluate.  Right now, my computer takes a long time to do decodes...   8 cores with new architecture will speed it up by just a little more than 2X, 10 cores nudges it up a little more.   AVX512 will speed up by about 30%..  3X speed improvement is very tempting.   I still must test for the SSE and AVX2 machines...  Will definitely think about it, but it will be 2-4months anyway before I buy the box.  (No more from-scratch MOBO for me -- I used to build  all of the time, and enjoy building them -- but my eyes and shaking don't make it easy.)

 

John

 

[John Dyson]

You know that I sometimes tweak on the decoder, and can always go back to the original/working version.   The EE/DSP types here understand what I am speaking about when I mention 'windows' for the FIR filters -- specifically the Hilbert transform filters that I use.   Because of very subtle phase variations and how they happen, the difference in window type, between Hann, Hamming, Nuttall, Blackman and Kaiser-Bessel are either variations on a theme or strangely different math, but generally produce a similar shape.  Hann is like a cos^2 shape, sort of the most generic.  Hamming is a simple variation that with a slight variation has a very different shape of it's ripples.

 

There is a filter that is especially good at the first sideband in some important respects -- it is a Kaiser-Bessel with its parameter generally 3 or bigger.  A long time ago, I started with a parameter of 4.5, but ended up backing off to 3.63.  The 4.5 requires more taps for the same bandwidth, but seemd to cause me troubles, so backed off to 3.63.  I just tried the 4.5 for the tuning parameter, and the sound was slightly better.  I guess we can chalk it up to bad tweaking in the past.

There is ZERO hurry in sending the 4.5 verison out right now.  There IS a difference, but not worth waiting for the next bug fix.  I might even find a better value for the parameter, right?

We are even down to subtle shapes of window functions to make improvements!!!

 

 

ADD ON:  Will be doing a new 'slightly better' release in a few days.  The current release is great, and the difference is so small that it REALLY is not worth a new release right now.   I just wanted to let you know -- I was just so surprised that I could hear a slight improvement.  Would you ever miss it in your recordings?  Nope.  It is just a fortunate tweak, that is IT.

 

John

 

[John Dyson]

We have hit the threshold for a new release -- SORRY! (in a way.)

The good news is that we all caught the problem!!!

There are also a super performance enhancement and a performance tweak/enhancement.

 

Most importantly, I have found that a lot of the problems in decoding Supertramp (and complaints) have been related to the EQ on the original tape being IEC, yet the tapes were probably played on a NAB EQ deck (or vice versa -- or whatever.)  I added a new switch to my test code '--oiec' for 'output IEC', with very pleasant results.  The difference is actually 'minor' in the schem of things, because it is a difference of a 4500Hz EQ vs 3150Hz, not all that severe.  But that dB or so can make your ears ring.

 

Already, there IS already an --iec switch, but that is for the input material.  I hadn't thought that the FA recording was created with IEC instead of NAB.

 

The new version V1.4.2A will have the --oiec switch, an improvement for the anti-MD filter choices, and a new secret swtich that turbocharges some of the anti-MD at the cost of about 20% slower decodes.

 

My first listen of 'crime' is sounding much more natural.

Will be testing/listening the rest tomorrow, and plan to make a release with the fixes/improvements tomorrow.

 

The real goal is to have the release ready for Friday night, but I suspect that I can make it ready for late tomorrow night or first thing Friday morning.

 

BTW -- the decoding parameters need not change,  but the change is in the new output EQ setting...

 

John

 

[lucretius]

13 hours ago, John Dyson said:

The usual values (sometimes spot-on) are -12.875, -13.425, -13.475, -13.75, -14.05, -14.35 -> -14.45 , -14.95, -15.05 and also have run into -19.425 and -20.35 on very premium recordings.   BY FAR, the most common is -13.475 (maybe -13.425 to -13.50).   Much of the time, you can just use --13.475 and be done.

 

Well, if -13.475 is by far the most common, then why is -13.425 the default? Or did you change the default (again)?

[John Dyson]

8 hours ago, lucretius said:

 

Well, if -13.475 is by far the most common, then why is -13.425 the default? Or did you change the default (again)?

You have a good mind and good memory :-).  The default is now -13.470 -- which is not substantively different from -13.475, and gives a slight bias towards previous good results a little lower.   The decoding calibration values in the -13.475 range are most often with a variance betwen about -13.42 though -13.50 (approx), but a difference of 0.025 is almost not important most of the time. I can actually hear a little difference at 0.02 sometimes, and I have heard subtle differences at 0.005, but they don't mean anything.   Much of the time, at the level of 0.01 or 0.02, I cannot really claim which is better.  People with better basic hearing than me should eventually be able to train themselves better than I have.

 

* After a lot of practice, I can visualize the decoding errors -- if there are any obvious ones.  Then, I tune the calibration, actually visualizing the distortion moving around temporally and in the spectrum.  Even with that learned skill, finding the calibration can sometimes still be a real challenge, and I still can make suboptimal choices.

 

Much of this extremely small calibration senstivity comes from two things -- the extreme precision and almost total lack of DolbyA HW decoding fog, plus there are sometimes differences which aren't really errors in the decoding -- just errors in the tracking between ANY DolbyA encoding/decoding and previews encode/decode cycles.   The more severe errors in the +-0.10dB range, which are noticeable as temporal movement in the decoder/expander surging.   At the +-0.50dB level, the movement in surging is very noticeable, on the other hand, SOMETIMES some recordings are so smooth that the expander surging is difficult to find at all..

 

Sometimes the surging can be percieved, then move the calibration around to find where it disappears -- it is tedious, but sometimes helps in cases where surging is noticeable.

 

* DolbyA HW decoding fog is good, in a way, because the little HF distortions are pretty much hidden -- the need for precision is less, but the details in the sound are hidden.  The --basic and --normal modes don't suppress all of the fog, and the slight leftover fog is a valid reason for keeping those modes.  --basic sometimes leaves a little more distortion/fog for my taste, but it has been beneficial in one or two recordings.

 

John

 

[John Dyson]

8 hours ago, John Dyson said:

We have hit the threshold for a new release -- SORRY! (in a way.)

The good news is that we all caught the problem!!!

There are also a super performance enhancement and a performance tweak/enhancement.

 

Most importantly, I have found that a lot of the problems in decoding Supertramp (and complaints) have been related to the EQ on the original tape being IEC, yet the tapes were probably played on a NAB EQ deck (or vice versa -- or whatever.)  I added a new switch to my test code '--oiec' for 'output IEC', with very pleasant results.  The difference is actually 'minor' in the schem of things, because it is a difference of a 4500Hz EQ vs 3150Hz, not all that severe.  But that dB or so can make your ears ring.

 

Already, there IS already an --iec switch, but that is for the input material.  I hadn't thought that the FA recording was created with IEC instead of NAB.

 

The new version V1.4.2A will have the --oiec switch, an improvement for the anti-MD filter choices, and a new secret swtich that turbocharges some of the anti-MD at the cost of about 20% slower decodes.

 

My first listen of 'crime' is sounding much more natural.

Will be testing/listening the rest tomorrow, and plan to make a release with the fixes/improvements tomorrow.

 

The real goal is to have the release ready for Friday night, but I suspect that I can make it ready for late tomorrow night or first thing Friday morning.

 

BTW -- the decoding parameters need not change,  but the change is in the new output EQ setting...

 

John

 

I am still doing the release, but after testing, and listening with more responsive hearing in the morning -- the IEC compensation on output did NOT improve the audio.

 

Much of the decoded intensity in the Supertramp recordings, which the recordings DO have intense dynamics, come from the perfectly fast responsiveness from the DHNRDS DA, while the real DolbyA units filter out a lot of transients.  That filtering is part of the DolbyA HW decoding fog.   The DHNRDS doesn't have the propagation delay through a compressor&filter array that slows down the synthesized expanders created from the feedback loop, and also the DHNRDS specifically mitigates a lot of the modulation distortion.  Both attributes keep the transients from being suppresed and mitigates the veil over the sound when decoding.

 

John

 

[John Dyson]

Heads-up on the new release.   I have promised my project partner the new release (a few more other changes), and so plan to be ready Sunday medium/early night (my time, USA EDT time.)   There will be corrections to the IEC input and output modes (there were some problems with them per feedback from my PP.)

Most importantly for FA decoding is the addition of the new mode characters '-' and '+', but mostly '-' will be needed.  Actually '-' already exists, but it had a bug.  There was some foresight in the design for certain situations that I knew about, but wasn't proven that the situation needed to be corrected.

 

Here is the new situation for the new, corrected '-' command:   you have some material where the sibilance or the highs are a little too intense.  You cannot tweak them out with --fb, --fc or -fD or the minor tweaks of 'x' 'X' or using the twist of 'a' or 'b'.   There is just TOO MUCH sibilance...  How do you fix it?  '-'.   What does '-' really do?  Well, not all FA uses exactly the same 'boost' at 3kHz, I found that some is 10dB (most often) and others are 9dB (2nd most often.)  Carly Simon and Judy Collins seem to like the 9dB mode, which is implemented by using '-'.   If you need more downwards correction (not likely), you can use more '-'.   I have run into very little (none so far) that needs the '+', but the character mode was added for symmetry.

 

What does Carly Simon EQ look like?  '--fb=-b'.   That's it.   This will NOT be fully implemented until the next release on Sun, but a bit of a hint of how it sounds can be verified in the 'V1.4.1F' release now, but it has a minor bug.  The current implementation will sound ALMOST correct for one '-'.   I'll document this in the 'decoding list' offcially when the new decoder is ready.   Carly Simon still sounds good without the '-' -- the recording that I have just has a bit too much sibilance from too much internal 3K boost EQ, and I need to make sure that there is NOT excessive sibilance for recording engineers to accept the decoder.  (Sibilance is a hot spot, because decoding unencoded material has sibilance, but MUCH MUCH worse than the manifestation of the situation that I am writing about here.)

 

Other than the new '-' and '+' mode caracters, there won't be anything really substantive (maybe the very slight MD changes,etc...)  Not worth seriously worth upgrading until the corrected '-' command came on the horizon.  (This posting is being made just as soon as I realized this new feature is going to be added/updated/corrected.)

 

Believe me -- there is a lot of flexibility built-in to the decoder -- but I believe that it is important to keep from complicating normal day-to-day decodes with fantastically complex decoding commands.   For example, the '-' command is a built-in 'macro' which does a set of operations that can be done directly on the command line as an add-on.  So, when you do a single '-', it is the same as instead using an additional --fbg=9 --fmd=9 instead (those numbers are dB values.)  No-one wants to worry about all of the numbers, but these commands are 'fixed' in the design also -- but PLEASE don't worry about these details.  This stuff is MY problem to translate into something usable, even for professionals.

 

John

 

[Skip Pack]

I've been working on my FeralA decoder 'plumbing'. I've now gat a Powershell script that will process every flac file in a directory and take it back to flac with versioning indicator. I discovered yeaterday that mp3tag will indeed copy all the tags from the input .flac files to the output .flac files. I don't think there's a command line way to do it but it's fairly quick through the mp3 interface. I may be way behind John here, but let me know if any of you need a how-to on the mp3tag tag copying operation.

 

[John Dyson]

Got an anecdote here -- but working on the release, and hope to get it out late tonight.  Sorry for the delays -- you know what I am tied up with this afternoon (like many of us -- Mother's day!!!)

 

Here is the anecdote -- was doing a test decode of a DolbyA master tape for Richard.  The DHNRDS test decode came out significantly more bright than a true DolbyA -- practically the same frequency spectrum, but the DolbyA damage appeared to be approx 3dB of transients compression over about 6-7kHz.   The DolbyA HW softened/compressed the high-hats, but the resutls certainly weren't what was originally recorded.   The DHNRDS passes through the highs very transparently, in fact a little too clean/clear (but accurately.)   I had used the wrong settings on the decoder a few days ago -- so did a retry.

 

Here is my mistake:

My second attempt was using a partially&incorrected edited DHNRDS decoder, and the >10.5kHz on the HF1 band wasn't working.  The result of that major botch using the bad version of the decoder, was an output VERY SIMILAR to a properly operating DolbyA!!! 

 

Basically, when analyzing my mistake -- the HF1 band on DolbyA HW is extremely non-transparent, as my mistake on the DHNRDS had effect primarily on suppressing a part of HF1 (the 9kHz -> inf) band, but not the 3kHz->inf band (yes, they overlap in a way.)  I never saw this before, but a lot of the DolbyA fuzziness appears to come from the HF1 band not being responsive.   This was an interesting learning exercise, but also shows that even when DolbyA material was previously correctly decoded, it STILL had defects that made a big part of the audio signal unavailable until the DHNRDS DA appeared on the scene!!!

 

BTW -- the test material is a moderately well known Jazz artist, recorded with technology able to push the quality of any audio system -- very good quality for testing, and except for the more clean highs and less muddy sound, the DHNRDS sounds pretty much the same.

 

John

 

[John Dyson]

New decoder version available, with a few nice new features.  The older version was okay, but ALL of my new decode examples will depend on some of the newly exposed features.  Basically, there had always been a quandry about vocal sibilance, and one of the biggest criticisms that I have gotten from people in the industry has been sibilance issues.  One thing that we fight when establishing credibility -- the DolbyA doesn't completely reverse its compression when being used in normal situations.  People DO get used to the compressed & foggy DolbyA HW sound -- but it is the DolbyA whose dynamics are not as accurate as the DHNRDS, not the other way around.

 

* There have been spits and sputters on determining the best features to expose to the users.  I think we have settled down to a reasonable minimum now.  I don't expect to add new decoding EQ modes unless someone else encounters something FeralA that cannot be decoded with the standard command set.  There are a lot of second level abilities that allow testing for non-standard decoding, and help me evaluate what features that might be added to the --fa type command set.  ALL PREVIOUS MODES STILL WORK -- there IS backwards compatibility.

 

The reason for the sibilance issues are not because of severe problems in the decoder, but instead any sibilance is a big red flag for many in the industry.  Anyway, any left-over sibilance problems are now handled very well.  There is a new document online called 'FixingSibilance.txt', which I will also post here.  This shows usage of the new options.

Frankly, I have found that the new options are REALLY nice, but unfortunately another small numbers of additional choices for decoding modes.  As an example of a beautiful decode done with the new decoder and new settings (there is only two series of settings -- not that big a deal) -- it is 'Please Mr Postman' on the DA distribution site.  Also, I am posting a link -- it is full high res, but of course needs to be limited in length. (mode is --fc=---b4.)

 

A new feature, documents don't talk about it, but the full professional manual will talk about it when updated:  'da.ini' file.  Most switches can be used in the file, and the first line is reserved for commentary that is displayed when running the decoder.   The single, one, da.ini file can be in the executable directory on Windows, or in the current directory.  On Linux, the da.ini file can be in the home directory or in the current directory.  It will be a persistent, forever feature -- I haven't documented it yet.  File specific switches are not allowed, e.g. --tone=, --input and --output.  However, general settings like --xpp are allowed.

 

The new version V1.4.2A resides in the following link.  The new using file, Sibilance help file and the high res snippet are attached.  The snippet is TRUE high res, and not just upconverted...

Repository:

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

Pointer to high-res snippet:

https://www.dropbox.com/s/4z0nxacrh7w38nj/13-Please Mr. Postman [1991 Remix].flac?dl=0

 

(I'll be updating the decode list items for @lucretius project and adding new ones soon.  Been very busy, sister having operation tomororw, but might add some tonight.  I am more happy than ever with the quality, and needs fewer compromises with the new sibilance control)

 

John

 

using-V1.4X-4.pdf install-V1.4.2A-Linux.txt FixingSibilance-V1.4.2.txt

[lucretius]

3 hours ago, John Dyson said:

A new feature, documents don't talk about it, but the full professional manual will talk about it when updated:  'da.ini' file.  Most switches can be used in the file, and the first line is reserved for commentary that is displayed when running the decoder.   The single, one, da.ini file can be in the executable directory on Windows, or in the current directory.  On Linux, the da.ini file can be in the home directory or in the current directory.  It will be a persistent, forever feature -- I haven't documented it yet.  File specific switches are not allowed, e.g. --tone=, --input and --output.  However, general settings like --xpp are allowed.

 

Hi John,

 

What do you mean by "file specific switches are not allowed, e.g. --tone=, --input and --output"?  Can we no longer use these switches?

[John Dyson]

8 hours ago, lucretius said:

 

Hi John,

 

What do you mean by "file specific switches are not allowed, e.g. --tone=, --input and --output"?  Can we no longer use these switches?

Sorry about my confusing writing.  My composition skills and organziation suck.

 

--tone=, --input and --output cannot be used in the 'da.ini' file, but can be used on the command line.   Maybe a default --tone might seem to be useful, but Richard didn't want people to get a sloppy workflow.   Disabling these switches in da.ini were explicitly requested.

 

Usefully, --overwrite CAN be used in the da.ini file.

 

AGAIN -- sorry about the confusion.

 

John

 

[lucretius]

2 hours ago, John Dyson said:

Sorry about my confusing writing.  My composition skills and organziation suck.

 

--tone=, --input and --output cannot be used in the 'da.ini' file, but can be used on the command line.   Maybe a default --tone might seem to be useful, but Richard didn't want people to get a sloppy workflow.   Disabling these switches in da.ini were explicitly requested.

 

Usefully, --overwrite CAN be used in the da.ini file.

 

AGAIN -- sorry about the confusion.

 

John

 

 

I think i get it now.  Putting some.switches in the .ini file helps to keep the command line shorter and more understandable.  As well, if those particular switches (i.e. the ones allowed in the .ini file) previously had a default setting, they are now more explicit/visible by specifying them in the .ini file. Where can I find the specs for the .ini file? And, how will this affect the linux version of the decoder?

 

 

 

[John Dyson]

On 5/11/2020 at 10:14 AM, lucretius said:

 

I think i get it now.  Putting some.switches in the .ini file helps to keep the command line shorter and more understandable.  As well, if those particular switches (i.e. the ones allowed in the .ini file) previously had a default setting, they are now more explicit/visible by specifying them in the .ini file. Where can I find the specs for the .ini file? And, how will this affect the linux version of the decoder?

 

 

 

Good question about the spec for the .ini file.   It is supposed to appear in the new professional DHNRDS manual, but I should probably write something up for now.   I'll get started on the stuff tomorrow morning.

About the linux vs. Windows version -- the only difference is the search list for the da.ini file...  There'll be at least some clarification/documentation.

Almost anything that is on the Windows version was tested on the Linux version *first*.   The search list, of course, is different.

 

John

 

 

John

 

[John Dyson]

Announcement:  there will be a new DHNRDS FA version coming out, ONLY with a metadata fix and metadata addition, absolutely no changes are being made to the sound quality and commands for now.   The metadata fix will be focused on 192k data rates in FA mode.  The metadata is somehow getting lost.

 

Also, some new metadata (probably LIST entries) will be added to log information about the DHNRDS decoding operation.  Hopefully, will be enough to reproduce decoding on a given recording based upon the metadata.  (the idea is that people can share recordings, without copying the recordings -- all that is needed is the FeralA copy and a copy of the metadata!!!)

 

I made a recent transcription error which made the Carpenters samples suboptimal.  I already wrote to @lucretius about the missing 'Q' character in the decoding mode on the HD carpenters examples.  Should have been --fc=---Qb4.   With or without the Q doesn't generally sound all that different, but the Q should be there and makes a profound improvement on vocal chorus.  When I previously 'bragged'  about the quality, I was referring to the version WITH the Q, not the mistaken version without the Q.

 

I am hoping that the additional metadata will help keep track when all worried/busy/under-pressure for anyone using the decoder.

 

Again, the decoder is pretty much frozen, and is very capable of amazing quality, but my HD carpenters examples made without the 'Q' wasn't the 'good sound' that we were all looking for.

 

John

 

[John Dyson]

Heads up about something that might seem like distortion or a bug when you look at a spectogram.  SOMETIMES, there is significant hiss, esp in a high res recording.   You can see all of that constant hiss on the FeralA copy when you gain-up and use wide dynamic range.

 

However, after you use the decoder, you can see the hiss appear as little spits and spirts -- that is NOT a bug, but simply what the decoder does -- turns the gain up and down, therefore modulating the signal and noise.   Attached is a before and after -- but again, you are NOT seeing distortion at all.

 

The top one is the hissy original version, and the bottom is the decoded one. That signal on the recording is a very pure EQed DolbyA -- I mean, it looks like not much 'love' was added.

 

The trick about those old NR systems is that the gain is turned down when there is less signal -- which undoes the compression which was done before it was taped.  You are seeing exactly correct (but strange looking) behavior in this picture.

 

 

John

 

[John Dyson]

I sort of promised a release today, but it will be tomorrow. Just got done testing/proving bug fixes.   I expect the release to be done some time 15May2020, in the morning EST USA time.  The sound is better, lots of little bugfixes on file compatibility, etc.

 

John

 

[John Dyson]

New release of the DA/FA decoder is ready.  New version: V1.4.3B -- look for files with this version in the repository.  The docs are the same, mostly bugfixes and minor sound improvements.  No settings changes required -- I have been/will be keeping the EQ the same, just minor revelations and adjustments.   This is mostly a bugfix release of most known bugs.

 

The 'ICMT' (comment) entry for metadata is edited, where the important decoding parameters are stashed there.   It appears that the output files work with mp3tag.

 

The short demo of 'Please Mr Postman' is updated, at 88.2k/24bits, 50secs.   The decoding parameters are now built-in to the file, and the metadata is intact.

 

Minor change, not yet documented: default output file format for FA mode is 24 bits (POLA* for consumers), but still FP for DA mode.  If you still want floating point, then just specify '--floatout' in the command line.

 

Repository:

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

 

More info will probably be forthcoming -- after a bit of a rest.

John

 

*POLA means 'principle of least astonishment'

[John Dyson]

Apologies -- there might be a bug in the code...  Gotta run it down.  Got feedback from my project partner with bad news.  Oddly, it was in a place that never gave me trouble in the past.  Will let you know when it is ready -- so -- if you try it, and it crashes -- I'll be fixing it ASAP.

 

The bug is NOT with the sound quality -- it is a stupid mistake by a clumsy programmer (me!!!)

 

It WILL be fixed tonight.

 

John

 

[John Dyson]

Good news, Richard and I found the bug -- it was a limitation while running in the Windows environment.  I just assumed that the code wouldn't run into the limitation (thread stack size), but unfortunately, it did.  So, instead of growing the thread stack -- it is already bigger than usual, I did the allocations on the heap.  In C++, it is easy to do cleanly and correctly.

 

Also, the .wav file parser was a little fragile.  Some of the professional .wav files present strange metadata items (like multiple LIST entries of size 4 -- strange.)  So, I double checked the parser, and made the code ignore insane metadata -- being more robust even if the files have serious errors in them.

 

This new release is V1.4.3D, and other than the correction for Windows, there is more robust .wav file reader.  Will probably add more cool metadata when I get back, but the decoder is REALLY GOOD.  I was just admiring it in DolbyA mode -- somewhat envious about how simple it is to use in DA mode.  In FA mode, we have to 'undo' damage -- which the decoder is VERY GOOD at cleaning up.

 

The new release is V1.4.3D, all of the same rules apply, and there are also Linux versions.

Repository:

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

 

John

 

[Audiophile Neuroscience]

On 3/21/2020 at 5:35 AM, dkskl said:

 

Yes. An intuitive GUI with guidelines would be incredible.

Let's see what the future brings… 🙂

 

Best wishes,

Soren 

 

15 hours ago, jabbr said:

I have been doing some decoding using my Linux workstation, and I have scripts to help automate the process. I guess at some point someone could write a GUI that would execute a command line program — I think the amount of time could be weeks for someone experienced in doing that type of coding ie I assume you want to use Windows. 

 

Thanks @jabbr

 

Yes, Windows

 

I have basic command line skills for specific tasks in Windows but a GUI for the decoder just seems less daunting.