'FeralA' decoder -- free-to-use

[John Dyson]

The new release might be delayed by a day or so...  I just told a DolbyA decoding customer that I'd be making it available on Wednesday.  Frankly, I got distracted, but also thinking about the best way to rework the complex interactions of the flow through the decoder and the .wav format.   There are little wierd rules in .wav files -- some forms require different capabilities -- the real mess is handling RF64, which I did  shoehorn in a few years ago.  Marshalling the data and all of the little tidbits is simple, but mixing it with a vast multithreaded structure is NOT simple.  This delay over the last few days has given me a good idea for a restructuring  - but again, it will take a few more days.   Instead of Monday, it will probably be Wednesday!!!

 

BTW -- the scary thing is making sure that through the > 16 threads, the data starts and stops at the same place...  LOTS of buffering...

 

Sorry!!!  It should be ready Wednesday though.

 

John

 

[John Dyson]

Gang -- I need help.  A AS user/listener about the FeralA decoder has asked for Led Zepplin test deocdes.  I cannot remember who!!!   Whoever is interested in Led Zepplin -- let me know, please!!!   I searched my records, but I get so overwhelmed, I cannot remember who?   I have an example to see if it is close...

 

John

 

[jabbr]

Led Zep — would be great to have the settings!

[Confused]

14 hours ago, John Dyson said:

Gang -- I need help.  A AS user/listener about the FeralA decoder has asked for Led Zepplin test deocdes.  I cannot remember who!!!   Whoever is interested in Led Zepplin -- let me know, please!!!   I searched my records, but I get so overwhelmed, I cannot remember who?   I have an example to see if it is close...

 

John

 

 

It was me!    (for the others reading this thread - John actually worked this one out, we have swapped a couple of PM's.  Oh, and the example mentioned sounds pretty decent....)

[John Dyson]

14 hours ago, jabbr said:

Led Zep — would be great to have the settings!

Along with the answer to this -- I have really good news about the .wav file handling.  I am really frightened of touching code that hasn't really been changed in 2yrs.  I forget a LOT!!!

 

Most important:

My first cut guess, and Mr 'Confused' (online name) gave some conditionally good feedback (per the follow up posting), here is the command line (in whole), and then the 'important parts' will be highlighted afterwards:

 

MY ENTIRE COMMAND LINE AS USED ON LINUX:

for fn in /fl2/music/Led*/*Holy*/06*.flac; do bn="$(basename "${fn}" .flac)"; echo "${fn}": ;  sox "${fn}" --type=wav -  |  ~/ap/nrs/dabuild/da-avx --outgain=-3.0 --info=2 --fb=x  --fd --tone=-13.45 --xpp  --wof=1.19  --affinity | sox -q - -d; done

(if not a Linux user -- don't try to parse it)

 

HERE IS THE 'MEAT' of the command:

EQ mode, calibration and stereo image correction:

 

--fb=x --wof=1.19 --tone=-13.45

 

EXPLANATION:

EQ:  '--fb=x', which is basically the following low pass filters of:

-3dB at 3k, -3dB at 6k, -3dB at 9k, -1.5dB at 12k

(using '--fb=X', changes the 12k filter to -3dB)

(using '--fc' modes, makes the cuts based on -4.5dB instead of -3.0dB)

* each filter isn't really at the single freq, but is split over a +-250Hz interval, for example 3k is really 2.75k,3k,3.25k -- the 250 Hz splits are TOTALLY important to mitigate IMD that appears purposely added for some strange reason.

 

STEREO IMAGE: '--wof=1.19'

Widens stereo image/corrects the L+R ratios, by 2^0.25 (or sqrt(sqrt(2.0))

Settings sometimes needed: --wof=0.8409, --wof=0.91, --wof=1.09, --wof=1.19

(not critical most of the time, but HIGHLY important on the Led Zeppelin recording.)

 

CALIBRATION: --tone=-13.45

This is the major, most prominent standard for the levels calibration on many FeralA recordings.

 

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

 

About the .wav file handling:

1) corrected the TOTAL .wav screw ups in the last release

2) correctly (hopefully) added the 'LIST' data

3) correctly (hopefully) added the 'id3 ' data

4) supported both upper and lower case tags

5) added the missing 'fact' data (technically optional, but programs complain)

6) lengthened the 'fmt' data to include the extended portions for FP data as well as int 24 * each filter isn't really at the single freq, but is split over a +-250Hz interval, for example 3k is really 2.75k,3k,3.25k -- the 250 Hz splits are TOTALLY important to mitigate IMD that appears purposely added for some strange reason. bit.

 

(I might consider adding the extended fmt for 16bit signed output, until I realized that the decoder doesn't support 16 bit signed OUTPUT anymore.)   Sorry about not supporting it -- I would only feel comfortable doing so if I was more competent about optimal dither for audio.  There is dither for the --intout mode (which is 24 bit signed), but dither at 24 bits is a much less critical thing than for 16bits.   The dither should be super well considered on 16bits for being optimum -- one doesn't want to add excess dither, but it is a good idea to be more careful about the spectral shape than my rather simple filtering/shaping used on the 24bit output.  Once I might feel competent to make the best choice, then might add an --int16out mode some day in the future. (Then, I can worry about extending the .wav file header for 16bits.)

 

The immediately previous release to the community (thank God, I didn't sent it to Richard), was really broken as strongly &kindly suggested by a user/contributor.  I am embarassed because of the extent of the error.  The bug came from a 'fix' that was not really a fix.   I forgot how the code handled 'tag' data that resided after the audio data, and a work-around fix was totally destructive.  Also, there were other problems added by yours truly.  This morning (just now) the decoder passed all of the tests sent to me by a contributing member on these AS forums and also still passes the standard RF64 (the super-sized RIFF/snd file format for pros) format also.   (RF64 is really useful for floating point full-album images, they sometimes get bigger than 2GB (like a 2,843,864,476 byte long FP professional album in my professional test collection).  On files that big, the size overflows a signed 32bit number.)

 

I am still testing the .wav file stuff, but I think (pray) that I am on track for Wednesday release (that is Wed evening, 29Apr, USA EST time.)   As you know, a promised release time is not always a good promise -- just wish me luck!!!

 

John

 

 

[John Dyson]

Announcement of hopefully something good and partial let down about earlier CPUs for a few days.   The build later this week for earlier CPUS will be EXACTLY the same version, but simply I wanted to make this available as soon as possible.  I just couldn't get the earlier i5 try done yet.

 

1)  Metadata should be a LOT more transparent.  Didn't just add/correct 'id3 ' and 'LIST' types, but a lot more pro types that were 'nice' to have, but I didn't previously do.   The only time that metadata will be fully intact is when doing direct .wav file I/O.  Pipes screw this up because the program seeks around through the .wav file to gather the pieces, but cannot do that with pipe I/O.   I prefer pipe I/O, so forgo full metadata transparency, but again, if you use the '--input' and '--output' options with .wav files, all should maintain metadata more intact.

 

2)  I updated the 'using' document with a caveat that not all CDs for the same named recording will require the same settings.   I also have found some of my choices in error.  This is because my hearing is NOT reliable, but usually the choices of '--fa=<number>', or '--fb=X', or '--fc=X' or '--fD=X' should be needed most often, where --fc and --fb version will likely cover 90% of the cases.

 

There are more announcements which I'll make later on tonight, and the pre-Atom/earlier SSE version for windows (which will work on earlier i5 machines) will be done on Friday.

 

Audio quality should be excellent, and no major changes at all.   More info to come, instructions should be pretty much the same EXCEPT the version is V1.4.1D -- the TOTALLY BOTCHED version is V1.4.1A, and might as just throw the da-avx and da-sse3 files away for that version.

 

* The only known problem with the .wav file on this version -- sometimes the .wav file is longer than the RIFF and RF64 length suggests.   I know what is wrong - and should never mangle the audio, it is just stuff off the end of the RIFF entry.  I have tried several various programs, and the file was not misunderstood.  It WAS nice to see the metadata pass through though!!!

 

It is in the same location as before -- repeated below...   I AM listening/watching for comments, and will do what I can to make it more usable every time -- feel free to comment.

 

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

 

[jabbr]

The Led Zep settings are good so far!

[John Dyson]

46 minutes ago, jabbr said:

The Led Zep settings are good so far!

Thanks!!!

 

You really gotta know though that my hearing is very strange and variable.  I have sometimes been totally confounded whether something should be '--fb=X' or '--fb=x' let alone SOMETIMES even '--fc=X'.  (--fc=X is not a strange setting, it is just that there is a substantial difference between, say, --fb and --fc=X.)   So, when I make a suggestion, it just might be wrong.   On the other hand, a correct setting is most likely available even when I am wrong, just that my suggestion might not be correct.  My estimations are usually best if I check over a period of two days, in the morning and evening -- then my guess is often close to correct.  

 

* A follow-on to this is that 'decoding' is best not done during periods of enjoyment.  The 'decoding' is a necessary evil preliminary to SOMETIMES get a better copy of the material.  Think of 'decoding' as an unpacking like ZIP.  The bad thing is that the 'packed' version almost sounds okay -- it is hard to get over the hurdle of that extra substantal work to get the more accurate copy.  Think of FA decoding potentially saving the cost of a HiRes download that would STILL probably not any better than your original.  FA decoding JUST MIGHT give you the recording that you originally wanted -- without the wasted purchase of the highres copy.

 

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

 

Here are some more technical hints:

Sometimes --fb=X or --fc=X might seem 'okay', but a little dull.*   I believe that the 'X' version of each mode is the 'standard', but sometimes using lower case 'x' instead can be helpful.   The lower case 'x' decreases the highest frequency attenuation by 1/2 of the number of dBs.   So, for --fb=X, each of the freqs is -3db at 3k,6k,9k,12k.  When you do --fb=x, then the gains are -3,-3,-3 but then -1.5 at 12k.   If you omit the 'x' or 'X' entirely, then there is no attenuation at 12k.   These filters in this sequence are 2nd order Butterworth shelving types (Q=0.7071.)  The EQ does appear to have been done in steps, not a tweak.

 

* if --fb itself is still too dull, you might try --fa -- some Linda Ronstadt stuff wants --fa=3, which means they did less EQ on it.  That doesnt happen very often though.

 

* if --fc=X is still too hot, then there is --fD (uppercase) using the same set of arguments.

 

* use --fd to get a dump of what the filters are actually doing.  Imagine that I use to set the filters individually myself in SOX!!! (lots and lots of twisting to put the signal into a CLEAN and DECODABLE state!!!)

 

If  you need a different rollof at 12kHz, instead of the variable 2nd order, you can make the rollof at 12k a 1st order by using the '4' filter.   So, --fb=4 gives the 12k filter as a 1st order.  You can even do --fb=X,4 which is just like the --fb=X sequence, but tacks on an additional 1st order filter -- believe it or not, that (--fb=X,4) is SOMETIMES needed on older material!!!  Older material seems to be created with more of the extreme settings.

 

I know that this might sound complicated, but really isn't.  It seems like 90% of the recordings can be gotten by one of the following:

--fb=X, --fc=X or --fa=classical,4 or --fa=classical,3 or even just --fa=classical.

 

The classical vs. normal 'pop' modes are a lot more different that just EQ -- suffice to say that the different modes ARE needed.  At times, you might even need the more complicated combinations where you tack on or change the following letters/numbers:  'x', 'X', 'y', 'Y', 'z', 'Z', 4,3,2,1,0.   while testing many, many CDs -- some (maybe 10% or less) need 2 or more combined modes. much of the time, they did sane things to the sound (if one calls 'FeralA' sane.)

 

It is hard to guess/reverse engineer all of the tweaks and tunes that were done during mastering...   It just so happens that much of the time, they did sane things to the sound (if one calls 'FeralA' sane at all.)

 

John

 

[jabbr]

Ok here is a tougher one: “1995 - Whitney Houston” ... I’ll go at it also but I’d really like to see what you do with this vocal 

[lucretius]

17 hours ago, jabbr said:

Ok here is a tougher one: “1995 - Whitney Houston” ... I’ll go at it also but I’d really like to see what you do with this vocal 

 

How about 1985 "Whitney Houston" and 1987 "Whitney"?

[jabbr]

11 minutes ago, lucretius said:

 

How about 1985 "Whitney Houston" and 1987 "Whitney"?

Ummm yeah 1985 Whitney Houston!

[John Dyson]

I am looking at Whitney sometime today.  But, work/problem solving before play, right?  🙂 Been resolving bugs (work, serious stuff before fun, right?).

 

There is a caveat especially when decoding POP CDs...  Some CDs are recorded HOT.  On top of that, the FA decoder has lots of EQ to correct for whatever evils they did while 'packaging' the recording.   Here is the problem -- the output of the decoder can be a LOT more hot than the input, by as much as 7-10dB, but is usually closer to 0dB difference, and more often no more than 6dB boost on peaks.   This is NOT a flaw, but a side-defect of all of the EQ needed, and the very hot input signal.  '--outgain=N', e.g. --outgain=-6 might be your friend!!! :-).

 

Note:  the input signal level is critical, and it is important that the signal that one decodes is at the same level as when the DolbyA was originally encoding the signal.   This is an impossible situation to guarantee, but it really does look like the levels are maintained in a sane way on most recordings that I have encountered.   The worst case isn't when the whole album gain was changed as a group, but instead when each recording was normalized by itself.  Unless you REALLY love that CD, don't even bother trying to make an easy decode (on those heavily normalized CDs) -- expect that the calibration level will have to be determined on a selection-by-selection basis.   Very often, though, when they have done normalization, it has been on an entire album basiss -- so you might need to change the EQ from the standard -13.45 (or whatever -- I forget) to -14.45 (for example) if the signal is 1dB hotter than it should be.   Choosing the calibration on a song by song basis will age you 10yrs for every CD you try :-).

 

OKAY -- Suggestion alternative #1 -- watch the output of --info=2, make sure that it doesn't clip.  Or, alternative #2 watch the output on a waveform display -- check for clipping.  If you get clipping, then add the following command option and redo the decode:

 

--outgain=-6  (or --outgain=-10, if -6 isn't enough.)

 

"--outgain=N" does the same as changing the output level by N dB.   The signal will NOT clip internally in the decoder, but when it converts to the output, then it can clip.  (signed int 24bits can only do +-1dB, and even FP isn't supposed to go out of bounds, even thought the DHNRDS will produce and properly utilize such floating point files.)

 

* I will make an action item:  ADD A MESSAGE that describes the amount of clipping on completion of the decoding.  This might allow short circuiting multiple decoding attempts to avoid clipping.

 

John

 

[jabbr]

Nice John ... I am finding that fc=x seems to tame the heat, and I will iterate on itone ...

[John Dyson]

37 minutes ago, jabbr said:

Nice John ... I am finding that fc=x seems to tame the heat, and I will iterate on itone ...

Sometimes, I'd like to be able to say that the decoding operation is a 'black box', which would be untrue.

Because of all of the evils done for mastering of digital material, it does require skill -- I don't think that the EQ can be resolved much more simply than the DHNRDS does.

 

* Never let my technical blather be a turnoff -- many of the internal details aren't needed.  All it takes is a bit of patience and reliable/repeatable hearing to get good results.

 

It appears that you are developing the skill -- but take care of your hearing.  Correct decoding is very dependent on stable/repeatable hearing...  That is one reason why my decodes sometimes don't sound right... 

 

The decoder CAN almost always do the decoding, but I don't have the skill or repeatable hearing to be reliable.  (Recently, I haven't run into ANY FeralA that the decoder cannot improve on -- but don't be fooled by properly mastered stuff!!!)  I have wasted time when trying to decode somethign that is not FeralA -- the first hint is that the correct calibration level is impossible to find.   Also, there can be expansion effects & surging when trying to decode material that is not FeralA.

 

I would be surprised if there is ANY digital FeralA material that the decoder cannot decode with its built-in EQ.  There are so many things built-in to it -- truly EVERY varation of decoding that I have encountred -- can be done.   I am hoping and PRAYING that the documented settings are good enough, because there are many more, less-documented settings that can give huge amounts of flexibility.  I don't think that most of the flexibility will ever be needed.  (Originally, I built-in the flexibility for testing, now the extreme settings are only a curiosity -- maybe somebody WILL run into something that has been EQed differently, and needs the more extreme settings.)

 

It seems that the most noxious combinations are the mix of 1st order and second order EQ...  That seems to happen more often on older recordings.

 

Also, it appears that the >3kHz EQ mostly needs to be 1st order for classical recordings (use a digit after the word 'classical', like --fa=classical,3).  For POP, they use a series of 2nd order filters.   The 2nd order filters appear to be interleaved at 250Hz intervals, which cancels out the IMD that happens if trying to do a simple set of filters.

 

Really, for a jolly time, take a look at the fiters generated for each mode, by just adding an '-fd' (lower case d) to the command line -- it will dump the FeralA EQ needed to convert the CD into DolbyA.  It took a LONG LONG TIME to ferret out (reverse engineer) the filters.

 

John

 

[jabbr]

Ha ha ... i have scripts that iterate over settings and i let the workstation crunch while I listen ...

so far I think I like fD=x and now iterating on tone settings ... vocals are tricky because its easier to make them worse...

I think the goal is to remove that upper end grit and let the music come through

 

Your settings for Led Zep come close to Barry Diament's remasters which is saying something, and still room for more tweaking

 

I must say that so far the Qobuz 24/96 version of "1985 Whitney Houston" is the best, but more work

[John Dyson]

38 minutes ago, jabbr said:

Ha ha ... i have scripts that iterate over settings and i let the workstation crunch while I listen ...

so far I think I like fD=x and now iterating on tone settings ... vocals are tricky because its easier to make them worse...

I think the goal is to remove that upper end grit and let the music come through

 

Your settings for Led Zep come close to Barry Diament's remasters which is saying something, and still room for more tweaking

 

I must say that so far the Qobuz 24/96 version of "1985 Whitney Houston" is the best, but more work

I am definitely gonna check into the Whitney stuff when I can!!!

 

About tweaking -- there are additional layers -- but it is tricky because things can go nuts quickly.  However, if you need hints and can explain the change in a raw technical way (very difficult), I might be able to help.  There are some subtle changes that might help midrange problems if you run into them.

 

*  Here is my rule of thumb:  sounding good is not necessarily 'technically correct'.  The decoder has mostly 'sounded good' for 2yrs, but hasn't been correct enough until recently.   There are two levels of decoding quality: 1) good enough to listen to, 2) good enough for very picky audiophiles.   The good enough for audiophiles is VERY frustrating :-).

 

There are some settings like --fbg and --fmd which might help at times (don't touch unless needed though.)  If one of those is messed witih wrongly, then the rest of the --fb, --fc get messed up.  However, if they are needed, then they can be lifesavers.  I don't remember the details, but  I believe --fbg and --fmd are both 10dB.  In strange cases, you might benefit by changing both of the values to 9dB.   (These midrange and 3k boost parameters should be the same, and are key to everything else being correct.  I truly hope that no-one runs into recordings that start needing these changes.)  Those are last-chance settings -- decoding quickly starts being 'not fun' when making too many changes.

 

I have found the midrange settings to be potentially beneficial ONLY on older recordings.  In fact, it has been so long ago, I cannot even remember enough to make that assertion.  Suffice to say, if you get balled up into something that just cannot be resolved -- there are a few rescue settings. 

 

Much of the time, an improvement can be made without attaining total perfection.

 

John

 

[John Dyson]

Heads-up on the calibration level for Supertramp early/non-remastered CDs...  I could have been wrong, and researching it.  The correct calibration level might be -14.05 instead of -13.45...  Just FYI.  I am still working on it -- I'd hate for anyone to waste too much time on it -- with my potentially incorrect values!!!

 

John

 

[lucretius]

On 4/29/2020 at 2:36 PM, John Dyson said:

1)  Metadata should be a LOT more transparent.  Didn't just add/correct 'id3 ' and 'LIST' types, but a lot more pro types that were 'nice' to have, but I didn't previously do.   The only time that metadata will be fully intact is when doing direct .wav file I/O.  Pipes screw this up because the program seeks around through the .wav file to gather the pieces, but cannot do that with pipe I/O.   I prefer pipe I/O, so forgo full metadata transparency, but again, if you use the '--input' and '--output' options with .wav files, all should maintain metadata more intact.

Hi John,

 

When I input 44.1kHz/16bit or 96kHz/24bit files, all metadata is passed through to the output file!  Impressive!

 

There is something strange going on when I input 192kHz/24bit files -- the tags are passed through (I know this because when I convert the output file to flac, all the tags are there.  However, the mp3tag program cannot read the tags for the output wav file. 

 

 

[One and a half]

Was finally game to try. Source files are all ABBA SHM-CD bought 2013 something CD Japan.

First up Voulez Vous, and some results, if you can call them that. OK where did it go wrong? As Good as new is AGAN.wav, converted from FLAC with dbpoweramp to 16bit WAV.

 

PC has twin Xeon, 16 cores, 50 odd GB RAM, so plenty of horsepower.

 

Microsoft Windows [Version 10.0.18363.815]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>cd D:\Music_Workshop\Restoration\ABBA

C:\WINDOWS\system32>d:

D:\Music_Workshop\Restoration\ABBA>da-avx --outgain=-4.5 --info=2 --fa --basic --input=1 - 01 ABBA - As Good as New.wav --output=outfile.wav
      0 [main] da-avx 364 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

D:\Music_Workshop\Restoration\ABBA>da-avx --outgain=-4.5 --info=2 --fa --basic --input=AGAN.wav --output=AGAN_D.wav
      0 [main] da-avx 1891 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

D:\Music_Workshop\Restoration\ABBA>da-avx --info=1 --fb=4 --tone=-13.425 --input=AGAN.wav --ovewrite --output=AGAN_D.wav
      1 [main] da-avx 1690 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

D:\Music_Workshop\Restoration\ABBA>da-avx --input=AGAN.wav --output=AGAN_D.wav --fa
      0 [main] da-avx 1297 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

D:\Music_Workshop\Restoration\ABBA>

 

Would also like to try a batch process.. like input *.wav output D:\AnotherFolder\*.wav? 

 

 

[lucretius]

delete

[lucretius]

34 minutes ago, One and a half said:

D:\Music_Workshop\Restoration\ABBA>da-avx --info=1 --fb=4 --tone=-13.425 --input=AGAN.wav --ovewrite --output=AGAN_D.wav

 

That should be --overwrite.

 

You can make any .bat file you want.  Here's my latest run.bat where I only have to specify the input filename, e.g. run filename.wav: 

da-avx --info=2 --fb --fgh2 --tone=13.425 --normal --input=%1 --output=%~n1_out.wav --intout

[One and a half]

1 hour ago, lucretius said:

 

That should be --overwrite.

 

You can make any .bat file you want.  Here's my latest run.bat where I only have to specify the input filename, e.g. run filename.wav: 

da-avx --info=2 --fb --fgh2 --tone=13.425 --normal --input=%1 --output=%~n1_out.wav --intout

Thank you, overwrite this time tried both and the batch file.

 

D:\Music_Workshop\Restoration\ABBA>da-avx --info=2 --fb --fgh2 --tone=13.425 --normal --input=%1 --output=%~n1_out.wav --intout
      0 [main] da-avx 1942 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

 

D:\Music_Workshop\Restoration\ABBA>da-avx --info=1 --fb=4 --tone=-13.425 --input=AGAN.wav --overwrite --output=AGAN_D.wav
      0 [main] da-avx 1542 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

 

There are two zips in the installer file, what to do with these? libao-master.zip & myaoplaysource.zip. Looks like the 2nd one is a player?

Command da-avx /? also reveals a stackdump..............

 

Now. Forget DA-avx.exe and try da-Win.exe.

 

D:\Music_Workshop\Restoration\ABBA>da-win --info=1 --fb=4 --tone=-13.425 --input=AGAN.wav --overwrite --output=AGAN_D.wav
Audio "DHNRDS DA decoder" V1.4.1D 29Apr2020 -- Author John S. Dyson -- Copyright 2017,2018,2019,2020
License terms are in accompanying documentation

Time Out:
Required CPU type: WIN64: x86-64bit with SSE: Silvermont or greater
Input file: "AGAN.wav"
Output file: "AGAN_D.wav"
----------------------------------------------------------------------------------------------------
....................................................................................................

Finished

D:\Music_Workshop\Restoration\ABBA>

 

Took about 20s or so for a 3:24 track, so a bulk album conversion won't take all that long. The output file is 32bit 88.2 & 4 times the size. The original sounds rather flat and dull, but not a fan of upsampling as exaggeration can creep in. We'll see with some more tracksnow that the conversion is working. Thanks for spotting the *overwrite*, just copying and pasting.

[John Dyson]

7 hours ago, lucretius said:

Hi John,

 

When I input 44.1kHz/16bit or 96kHz/24bit files, all metadata is passed through to the output file!  Impressive!

 

There is something strange going on when I input 192kHz/24bit files -- the tags are passed through (I know this because when I convert the output file to flac, all the tags are there.  However, the mp3tag program cannot read the tags for the output wav file. 

 

 

Okay -- there is a dirty little secret going on in the 192k/24bit (and other rates) files.   Here is what happens -- the decoder cannot do anything more witih 192k files than it can with 96k files.  It has a HARD frequency response limit of 40kHz to moderately closely match the behavior of a true DolbyA.  SO, the decoder does a straight 2:1 conversion on input and the converts back on output.   My guess (and I'll look at it) is that I made a mistake for that specific mode.  There is ZERO signal loss on doing the conversion -- but then, why do the conversion?  Long long story below:

 

Let me explain -- it might seem like I am 'cheating' by doing the down/up conversion, and in a way I am.  However, there  are some math problems with running the decoder at 192k...   I am not trying to be overly deep-tech-talk, but basically there are some filters and hilbert transforms in the code ( A LOT OF THEM), and to avoid lots of multi-rate/poly-phase games on a dynamic non-linear system (things don't work together simply), all of the signal path is at the same rate without poly-phase with potentially strange side effects.  (The signal level detectors DO use rate conversion, but not in the signal path itself.)

 

A lot of the filters need to have fairly narrow skirts, so need lots of taps (again, not doing polyphase because of the dynamic gain stuff -- not sure if it can work at all).   The number of taps needed increase based on sample rate, including for the Hilbert transforms some of which need to produce usable results down to below 300Hz (usable means 0.1% accuracy.)  Some of the filters need so many taps that they must be double precision, which slows them down further.

 

So, as a tradeoff, I limited the number of filter taps, therefore the high quality anti-distortion (removing modulation distortion) code only works well up to about 100kHz, and works best at 60-76kHz range.   For best quality, it is actually important to bring the sample rate down to at least 96kHz -- it isn't simply due to laziness, it was a set of complex, almost imponderable tradeoffs!!!

 

No matter what, I will look into what I did wrong to the metadata on 192k!!!

 

John

 

[John Dyson]

4 hours ago, One and a half said:

Thank you, overwrite this time tried both and the batch file.

 

D:\Music_Workshop\Restoration\ABBA>da-avx --info=2 --fb --fgh2 --tone=13.425 --normal --input=%1 --output=%~n1_out.wav --intout
      0 [main] da-avx 1942 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

 

D:\Music_Workshop\Restoration\ABBA>da-avx --info=1 --fb=4 --tone=-13.425 --input=AGAN.wav --overwrite --output=AGAN_D.wav
      0 [main] da-avx 1542 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

 

There are two zips in the installer file, what to do with these? libao-master.zip & myaoplaysource.zip. Looks like the 2nd one is a player?

Command da-avx /? also reveals a stackdump..............

 

Now. Forget DA-avx.exe and try da-Win.exe.

 

D:\Music_Workshop\Restoration\ABBA>da-win --info=1 --fb=4 --tone=-13.425 --input=AGAN.wav --overwrite --output=AGAN_D.wav
Audio "DHNRDS DA decoder" V1.4.1D 29Apr2020 -- Author John S. Dyson -- Copyright 2017,2018,2019,2020
License terms are in accompanying documentation

Time Out:
Required CPU type: WIN64: x86-64bit with SSE: Silvermont or greater
Input file: "AGAN.wav"
Output file: "AGAN_D.wav"
----------------------------------------------------------------------------------------------------
....................................................................................................

Finished

D:\Music_Workshop\Restoration\ABBA>

 

Took about 20s or so for a 3:24 track, so a bulk album conversion won't take all that long. The output file is 32bit 88.2 & 4 times the size. The original sounds rather flat and dull, but not a fan of upsampling as exaggeration can creep in. We'll see with some more tracksnow that the conversion is working. Thanks for spotting the *overwrite*, just copying and pasting.

Yea -- da-win is a backup just in case da-avx doesn't work.  I actually test da-win better than da-avx -- because I don't have a windows da-avx machine, but only a Linux da-avx machine.   da-avx actually needs AVX2, which isn't even in some of the recent AMD (at least, I think that is true.)   The AVX2 makes a nice speedup, but I always made sure that the decoder would work on machines without (or with less) SIMD also.  (I haven't done a P4 build, whDOich has much less useful FP SIMD, for a long while, but intend to do so very soon.)  Very early versions could be built for ARM NEON also, but I haven't bothered with that for 3-4yrs.

 

I know that it is a little bit concerning that multiple program versions are needed.  Using internal CPU selection would have slowed down a lot of the code -- I am not sure if it would have been an extreme slowdown, but would be noticeable.  The code is VERY tightly written -- and when the decoder is running on an SIMD machine, it is running in SIMD code well over 95% of the time -- the math is heavy and intense.  Needing to vector based on CPU for so many operations would hit the speed significantly.   It is definitely a burden to support multiple versions (when also supporting Linux now also), but I think that it is worthwhile to do so.

 

The aoplay program supports the --play option on Windows.  There is also the --splay option, which uses the SOX command (the installation package is on the distribution site.)  The aoplay program is a minimal realtime play program -- but since it uses a GPL (or LGPL) library, I simply supply all of the source code.  I didn't want to get into the licensing problems -- so I am careful, when dependent on GPL or LGPL code to make sure that my own code is 1) never dependent on code with GPL semantics to run...  2) never modify GPL or LGPL code unless I make the source available.  (that is, use any GPL/LGPL libraries as is so that the source can be retrieved.)

 

The decoder itself NEVER depends on GPL/LGPL or other conditionally free software -- so that there are minimal license encumberances.  I DO plan to disclose the technology some day (probably relatively soon), but want to do so in my own time.   The big problem about a major part of the decoders' technology is that I don't have the math skills to prove the anti-modulation-distortion code -- but I know it works.  SO, I don't want to disclose/document the code until I am actually intellectually prepared to do so.

 

John

 

[jabbr]

Wow! using settings fD=x tone=-13.45 wof = 1.19 on “1985 Whitney Houston” is remarkable — I need to turn the volume up by 3dB to get the same effect, that is it removes the painful HF grit from my ears    
 

This is now better than the Qobuz 24/96 (obviously remastered!) version