'FeralA' decoder -- free-to-use

Here is the promised FeralA decoder.   It hasn't been through the full Windows testing, but I have been beating the Linux version up for quite a while.   There were a few last minute fixes -- like usual, as I am famous for 'stuttering' when I release software.   I come from the good old days where there were actual software testing groups -- -no longer have that luxury.

* I fully expect that the decoder might be frustrating to use at first -- contact me if you have problems.  I'll try to answer/help reasonably quickly

There is a .txt file that describes lots of various commands and options along with a general purpose manual for the full decoder -- too complicated for what is needed for FA decoding.

This is a *command line* program, very ugly to use by today's GUI standards..  The program does work if you can get past the command line issue.

This program also contains a DolbyA compatible decoder, but won't work as a DolbyA decoder unless you have a license file.  I'll make you one if you want to try actual DolbyA decodes instead of FA decodes.   The FA decodes are specified by using the --fa switch early in the command line.

For just playing around, you can just use the command line in the same directory as you unpack the binaries.   Eventually, you might want to stash the binaries (all of the files in the distribution) into another directory, and use the PATH environment variable...   My guess is tha only 10% at most of the people who actually try to use the decoder will be happy, esp since the program is command line.

So 1)  Unpack the program.  2) find a CD .wav file 3) decode the CD .wav file 4) play the result, assuming that the file is 'normal' (which is probably 3/4 of the proper feralA recordings.)  One note:  many feralA recordings HAVE been molested by the distributor, so sometimes it can be hard to find a good .wav file.   When you do find a good wav file, then the program should work fine...   Here is how to do it: (assuming you have an AVX compatible CPU use da-avx.exe, otherwise for older SSE only CPUS, use the da-win.exe)

(also, with --info=2 you get the full progress indicator, while if you use --info=1, you get 'dots' across the screen)

>  da-avx --outgain=-4.5 --info=2 --fa --basic --input=infile.wav --output=outfile.wav

(command above is the lowest quality, but fastest decode -- still better than if you used a DolbyA)

If you have a .flac file, and use/have sox -- you might be able to do this:

>  sox input.flac --type=wav - | da-avx --outgain=-4.5 --info=2 --fa --basic | sox - outfile.flac

If everyting is working okay, you MIGHT be able to play the .wav file output instead of saving it to a file:

>  da-avx --info=2 --fa --basic --input=infile.wav --play

Good luck, contact me either in this forum for general questions, or PM me if you want to talk about this privately.

Remember to look at the documents in the download area.

Note that I fully own the software, and have given you permission to do FA decodes to your hearts content.

(Note that reverse engineering might be fun -- the binary is really evil/ugly :-)).  When I have had to look at the binary to effect

bug fixing -- it is really entertaining to see how efficient the compiler is, producing really good SIMD code...  It is AMAZING.

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

I'll probably update the code as I find bugs (hopefully none or minor.)

John

Heads up.   Using the --iec  switch in FA mode on the version of the decoder on the Dropbox site, I just decoded all 8 major ABBA albums.   Of course, I have pristine FA copies of their albums, but even mangled versions work pretty well.  The sound quality is really good -- perhaps add maybe 0.75dB of bass at 1kHz and 750Hz both, and the sound is as good I have ever gotten.  Perhaps it needs the --fw=wpop switch, which widens the stereo image a little bit (by a crafted factor of sqrt(sqrt(2)) or about 1.19.  It seems like the FA creating process does a bit of narrowing.   But even with the slightly narrow image, the sound is fantabulous.

One important thing, I forgot to mention -- trying to decode material that has been normalized just creates a lot of work.  When material has been normalized, the level relationships are all messed up.  As is, most material is happy being decoded at a calibration level of --tone=-12.85 or so, but when the levels have been changed, then the tone value has to track the levels -- makes for a lot of work.

A good rule of thumb, never normalize the levels when you rip material!!!   After you rip it, then keep that copy, and make a manipulated copy if you want.

The decoder also works with .mp3 or .opus data, but of course, it has to be converted back to .wav so that the decoder can use it.  If  you find FA vinyl, it also helps to reduce rumble.  (The freqs below 80-100Hz are processed seperately.)

John

It appears that the FeralA format also includes a mild bass cut in some cases.  Specifically, it appears that for the best quality, decoding the ABBA recordings require a slight bass boost to compensate.  I kept hearing something unsatisfying, but still excellent.  That is -- something has been 'wrong', but not sure what.

Note that I listen very carefully when I have my engineering hearing on.  The problem has been just a little too much IMD in the lower midrange/upper low end.  I don't know if most people can hear the defect, but it is fairly obvious once made aware of it.  The IMD happens because of gain mismatches in the lower freq ranges.

I'll be doing a new release in the next day or so, I am aggressively testing right now.   The improvement will be an addition of 3 LF boost filters, they are 2nd order LF shelving boost.  The defaults will be 1kHz, Q=0.50.  750Hz, Q=0.50 and 45Hz, Q=1.0.  Normally, their gains will be zero (disabled.)   Controlling the filters will be accessible by the command switches:

--lf0gain=xx, --lf1gain=xx, --lf2gain=xx  (modify the shelving bass boost gains)

--lf0freq=xx, --lf1freq=xx, --lf2freq=xx (modify the shelving bass boost freqs)

--lf0q=xx, --lf1q=xx, --lf2q=xx (modify the shelving bass boost Q values)

These switches will be added in the next release -- probably Sunday night (approx 28Hrs from the posting time.)   I am doing the ABBA decodes with the additional switchs of: --lf0gain=0.75, --lf0freq=1000, --lf0q=0.50 and --lf1gain=0.75, --lf0freq=750, --lf1q=0.50.  Adding these switches is identical, but more accurate than the sox commands:

bass +0.75 1000 0.50q

bass +0.75 750 0.50q

John

Hey there John,

Playing with your software on some old ABBA - first press "W. German" Polydor CD from 1992. Very clear difference and the decoding does improve the high end. At least on the songs I tried, I agree the bass boost is a good idea. At times the highs can be a bit harsh even though overall the sound is "more right"!

Keep up the good work ;-).

Now that I've heard the difference this makes, I'll need to be on the lookout for more albums that could be improved. Have you been keeping a list of CDs over the years you've come across that would benefit?

29 minutes ago, Archimago said:

Playing with your software on some old ABBA - first press "W. German" Polydor CD from 1992

 POLCD-242 from 1988 was possibly one of the best sounding versions.

http://www.getabba.com/collection/cds/cd_ringring_official_SWE.htm

1 hour ago, Archimago said:

Hey there John,

Playing with your software on some old ABBA - first press "W. German" Polydor CD from 1992. Very clear difference and the decoding does improve the high end. At least on the songs I tried, I agree the bass boost is a good idea. At times the highs can be a bit harsh even though overall the sound is "more right"!

 

Keep up the good work ;-).

 

Now that I've heard the difference this makes, I'll need to be on the lookout for more albums that could be improved. Have you been keeping a list of CDs over the years you've come across that would benefit?

 

First, I am very happy that you got the decoder working...  Does the --play mode work for you?  It is very new, and I am a little sketchy about doing stuff on Windows.

About the ABBA sourcing...   I can find some IDs for other CDs from other groups also.  I have metadata online for many/most of the recordings that work well.   If the CDs are relatively early, the hitrate is actually very high.  Later on, when loudness wars starts kicking in, then the hitrate becomes better with HDtracks type downloads.

Here is a posting that I made in Hoffman's forum a few days ago -- it lists my current ABBA source material -- and also a revelation that I actually had a better copy of SuperTrouper than what I had been previously using.

The new decodes on the 'review' area will include the NEW Supertrouper copy, as derived from an early Polar release instead of the version that was I was using.  The difference in compression was minor, but the stability of the sound/keeping the organization of the vocal chorus is better in the new decodes/the early Polar CD.

I have found that some of the Polar and Polydor CDs are indistinguishable.

---------

Here are the best, most unmolested EQed DolbyA copies that I have (these have the least compression, EQ.) They decode into pristine results -- REALLY pristine, even though they are normal compressed DolbyA when listening to them:

ABBA P33P 20056
The Visitors CDP-101
Voulez Vous CDP-106
Ring Ring POCP-2201
The Album CDP-105
Arrival CDP-104
I don't have online metadata form my SuperTrouper and Waterloo disks. My SuperTrouper disk is especially clean to start with.
However, my original Polar Super Trouper might actually be slightly better than the CD that I have been using. I decided to review my choices
while responding to you about this. I just did an EQ and DolbyA decode, and my Polar Supertrouper IS better than the one that I was using!!! Amazing!!!!

I have other SuperTrouper disks, I mean CDP-102 isn't bad -- but isn't as good as the one that I am using (in my storage bin.) And apparently not as good as my Polar SuperTrouper!!! I am kind of embarassed now .

John

1 hour ago, sandyk said:

 POLCD-242 from 1988 was possibly one of the best sounding versions.

 

http://www.getabba.com/collection/cds/cd_ringring_official_SWE.htm

I just did an analysis of the 'Ring Ring' wav file that you sent a few months ago...  Indeed, it is a pretty good copy.  It passed a couple of my objective tests as being similar to the version that I use.  It *is* different, but within reasonable bounds as being fairly close to mine.  (we are talking 0.1dB differences, not like the substantive 0.5dB differences that show a very different version.)

It MIGHT be better -- it is hard to tell because the song 'Ring Ring' really doesn't show the IMD and garbled chorus effects like other songs do...  However, just listening to the FeralA source material in that wav file, it doesnt' sound bad (hard to tell without decoding.)  My machine is 100% tied up just this minute re-decding Brasil'66 and Tijuana Brass (at the absolute max quality mode) for testing.  When it is done, I'll do a quick check, but it does look like the file is good.

PS:  did some more analysis -- yours has fewer errant peaks than my original.  I don't know what that means WRT quality -- either way could be better (one could be clipped, but mine might be modified in some suboptimal way causing phase problems.)   The 242 has lots more 60Hz hum than mine (the version that I use doesn't have noticeable hum in the spectogram), but both have a 15kHz or so pilot tone of some kind.

John

Must it be a WAV file from a CD, or can it be a WAV file that I'd convert from an AIFF rip, for example? If I ever get some time, I might try this on a track or two from the famously ruined-by-bad-Dolby "Katy Lied" by Steely Dan.

6 minutes ago, Jud said:

Must it be a WAV file from a CD, or can it be a WAV file that I'd convert from an AIFF rip, for example? If I ever get some time, I might try this on a track or two from the famously ruined-by-bad-Dolby "Katy Lied" by Steely Dan.

As long as the levels haven't been changed (no normalization) and not much filtering had been done, it should work fine.  The decoder will even work on material that had been mp3s or opus.  If a file sounds like it hasn't been changed, then the decoder will most likely work okay.

Little phase errors above 1kHz are almost meaningless to the decoder.   The lower frequencies are more phase sensitive, esp below 200Hz, because the LF and MF bands need to 'dance' together intimately, or there will be a sense of LF distortion.  It isn't severe though, and I am speaking from a goal of perfection.

So, yes, as long as a compressed file (either just space compressed or mp3/opus/other compressed) has the same levels and not too much filtering, and then re-constituted to .wav  -- all should be okay.  On the filtering -- even 0.5dB at 10kHz can make a noticeable difference, but it isn't a killer.  Most likely, frequency response errors cause a bit of a damaged sibilance or something like that.

Sample rates of 44.1k, 48k, 88.2k 96k and 175.4k, 192k work.  In fact, any sample rate between 44.1k and just above 96k will work along with 176.4 to 192k will work.  It needs 16bit, 24bit or floating point input.  It will output floating point unless you specify --intout, which will then be 24bits.   If you input 44.1k or 48k, then you'll get 88.2k or 96k.   The decoder does NOT like running at slower rates, so it automatically upconverts.  The anti-distortion math doesn't work well at 44.1k and barely works well at 48k, so I do internal up-converts.   Normal, raw, primitive decodes work just fine internally at 44.1k and 48k, but there is no real disadvantage to running internally at a higher rate anyway.

John

19 minutes ago, John Dyson said:

The 242 has lots more 60Hz hum than mine (the version that I use doesn't have noticeable hum in the spectogram), but both have a 15kHz or so pilot tone of some kind.

 John

 15,625 HZ perhaps ?

14 minutes ago, Jud said:

Must it be a WAV file from a CD, or can it be a WAV file that I'd convert from an AIFF rip, for example? If I ever get some time, I might try this on a track or two from the famously ruined-by-bad-Dolby "Katy Lied" by Steely Dan.

Somehow I destroyed a nice long wordy post as I was typing it...  I'll have to give you a simple answer now:

As long as the levels haven't been changed and not much filtering was done, a wav file that was once a compressed mp3, opus or other kind of compression will work fine.   Of course, flac will work all day and night.

The only caveats are 1)  Normalization, 2) too much filtering (some is safe), 3) below 128k might start being problematical.

Above 1kHz, phase isn't really an issue.   200Hz on down is somewhat important, because the attack/release work hand in glove.

John

1 minute ago, sandyk said:

 John

 15,625 HZ perhaps ?

Good idea -- if it on both of ours, probably on the very original recording.   I have attached the spectogram.  I didn't notice before that it was on only one channel...  (The example that I included was from your .wav file.)

I sometimes look at this stuff, not because I can hear it -- but it is good for guessing at previous environments.  Estimating recording quality issues, etc.

John

4 hours ago, Archimago said:

Hey there John,

Playing with your software on some old ABBA - first press "W. German" Polydor CD from 1992. Very clear difference and the decoding does improve the high end. At least on the songs I tried, I agree the bass boost is a good idea. At times the highs can be a bit harsh even though overall the sound is "more right"!

 

Keep up the good work ;-).

 

Now that I've heard the difference this makes, I'll need to be on the lookout for more albums that could be improved. Have you been keeping a list of CDs over the years you've come across that would benefit?

 

Referring to you comment about the highs being 'harsh'.  I re-reviewed the sound, and I agree with you 150%.  This harshness resulted from a suboptimal choice for the input filter -- where I programmed in 2 standard filter sets plus two adjustable filters that can be used in combination.   I had used a 1st order 9k and 12k filter before decoding.  That amount of filtering wasn't enough.  This kind of error is normal because the straight EQ probably ended up to dull, so they brightened the results.  They seem to use a standard series of 4.5k, 6k, 9k and 12k filters.  I changed the filters to 6k and 12k for the ABBA decodes, and it seems like the results might be more 'normal' sounding.

The new decoding results will have both the improved LF EQ and the 6k & 12k instead of 9k & 12k.

I'll also update the documentation to reflect these options along with the new decoder release.

John

Next release and next group of demos:

Might be delayed by up to about 1 day.  My decoding results are coming out 'okay', but trying to make sure I fully understand the sound that I am getting.   The results have NOT been bad, but the results are alittle softer than usual.  It could be a result of the stronger LPF on ABBA recordings -- where the stronger LPF was/is really needed.  There are some EQ tricks, esp before the fast expansion, where we can get a 'stronger' sound yet also do the needed rolloff...  These kinds of changes often require careful consideration.

Once I am happy with everything, and it will be very soon, I'll do the release(s).

My only worry is that the decoder has started getting a case of "creeping featuritis", and I also need to re-evaluate the features.

The next release will probably be before tomorrow night (that is before approx 30Hrs from now.)

Even though nothing has been perfect in the results and the decoder, I AM a perfectionist, and if there are any nits, then they will be fixed (or I'll worry myself to death about the problem :-)).

ANYTIME that a delay that I cause might ever cause someone a problem -- let me know ASAP, because I can resolve simple problems pretty quickly.  The issues that I am dealing with right now: "understanding the sound characteristics", and "re-evaluate the feature/command set."

John

Wow -- many of you know that much of my windmill tilting has been attempting to properly decode the FeralA ABBA material.   This recent improvement is something that is a real, actual technical lesson...

As you know, when processing something complex, like music, there are all kinds of frequencies, lows and highs.   If the gain changes from the low frequencies modulate the highs, then the sound becomes fuzzier, softer or even as bad as being 'buzzy'.   This is a bad thing, and is similar in SOME WAYS as a single speaker diaphragm being used for the highs and lows -- they will all modulate together.  The speaker modulation is doppler and more like FM.  This 'gain control' modulation is more like AM, and so produces a different set of sidebands, even though the effect is similar.

Well,  I KNOW for a fact that ABBA should sound fairly clean -- but my results never sound really clean.  I haven't ever heard a perfect rendition of ABBA recordings, even though I hope that the DHNRDS FA is coming close.  The vain attempt to clean-up the sound encourages me to allow a little too much HF into the decoder, therefore causing a harsh sound.  There was always a kind of modulation to the highs that I always had problems trying to pin down.   The DA decoder is incredibly aggressive at mitigating modulation effects, but if the material is somehow defective or is presented in a defective way, then there be dragons -- no matter the magic in the DA code.

This ABBA decoding has been a goal, because I know that it is difficult to get excellent results.  If it was easy to decode ABBA like it is ONJ, then I'd be working on the next project right now.   FA is not done yet, even though DA is pretty much complete (totally.)   Well, almost.

I don't know if I found a bug in the DA or the problem is with the EQ filters for the FeralA decoding, but I found an interesting tidbit.  This tidbit is that if I give a VERY VERY slight bass boost to the input of the DA from the FeralA source (that is, modify the corrective EQ), then the fuzz significantly diminishes, then the temptation for too much treble also diminishes.   In a way, the slight bass boost almost gives an effective treble boost because the signal lines up with itself better. 

* the optimum amount of boost appears to be approx 0.75dB -> 1.0dB with a wo (frequency knee) of 1kHz.   It appears that a single pole boost or a 2nd order boost with Q=0.50 give similar results.  I will do some experiments to find the exact best choice, and make the option available on the command line.

As a more complete experiment, I modified the EQ code for the FA mode of the decoder where if I give that slight bass boost on input of the decoder, I do a 100% complimentary bass cut on the output, so if the decoder has zero dB gain at the time, then there response is effectively flat.

The interesting new result is that the slight fuzz now diminishes very significatnly, and also we don't get an excessive bass boost.  To me, a 0.75 + 0.375dB bass boost is way way too much.   The DA decoder has to be accurate to within about +-0.35dB, but if it doesn't keep good accuracy I feel like it sucks.  For FA mode, any accuracy is good (IMO), but I hate to waste the approx 1dB in error just to get rid of the fuzz, right?

Anyway, good news -- I keep on learning and learning and learning -- with the encouragment of some people who have been helping & reviewing -- THANK YOU.   I believe that the upcoming ABBA decodes will definitely sound better, have less of the excessive highs, yet be more clean, an little more transparent sounding -- still not perfect!!!  I am trying!!!

Thanks again everyone, and I hope to get a release and some ABBA demos (and probably others) uploaded by about 30Hrs from now.  I keep slipping, but this minor breakthrough has taken some time to analyze.

John

Can you make a plug-in for Logitech Media Server. This would make it easy for people to try it. 

38 minutes ago, vortecjr said:

Can you make a plug-in for Logitech Media Server. This would make it easy for people to try it. 

Man -- to port the entire thing to a plug-in environment would be a major project.  The program runs in about 15 threads, and grabs most of the CPU at realtime for the higher quality decodes.   I wish I had the ability to write plug-ins, but that requires the tools, the facility (the server itself), etc..   I don't even program on Windows at all -- I just port and build it for a release.  (I am not even typing on a windows box -- seldom, if ever use windows for anything but building a windows version of the decoder.)

The full-on decoder probably wouldn't be able to fit into a normal plugin environment -- it is mega-complex.  It is really intended to run ONCE per recording, similar to the mastering process.   Basically, even though the program looks small, it is a total monster -- really.

I would be happy to provide a simple version of the technology for casual plug-in use, but I don' thave ANY facilities to do plug-ins.  So, if someone likes to write plug-ins, and is familiar with SIMD programming, I can provide stripped down code that will do about the same (slightly better) than a true DolbyA.   I simply cannot do it.  (I am willing to license the technology gratis for commercial purposes, just credits would be sufficient to me.)   And yes, even the basic decoding technology is complex enough to be something that would be licensed, let alone proprietary anti-IMD stuff (which probably can get by without for Feral decoding.)   No one has done a full quality SW decoder before.

The good news would be -- the simple version of the decoder could run EASILY in realtime.

So, sorry I really cannot do it by myself -- but I am DEFINITELY willing to help someone to make a plug-in.

ADD-ON:  maybe not making myself clear -- PLEASE, someone who likes to write plug-ins -- I am willing to give the 'secrets' and all of the research for simple decodes so that at least reasonable quality decodes would be easier than my full-out decoder-monster.  There is a LOT in the decoding process itself -- REALLY, TRULY a LOT.

John

Hello John,

I was pleased to see your first post in this thread, and just got to work setting it up. I've tried two command-line invocations, and I get the same stack dump as below:

C:\Users\Skip_Active\Music_Processing\working>da-avx --input=gs01.wav --fa --tone=-12.87 --xtra --output=GS01_def1.wav

      0 [main] da-avx 1173 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

C:\Users\Skip_Active\Music_Processing\working>da-avx --outgain=-4.5 --info=2 --fa --basic --input=gs01.wav --output=GS01_basic1.wav
      1 [main] da-avx 1704 cygwin_exception::open_stackdumpfile: Dumping stack trace to da-avx.exe.stackdump

My cpu is a Core I5 3470 with plenty of memory and has the AVX instruction set. I tried da-win and it runs fine (no serious listening yet).  It did take a fair while to finish with da-win, though that isn't terribly important to me. I don't expect to use the --play option much.

Please let me know if you would like me to try any specific parameter sets.

Skip

Oh my -- this explanation was my fault -- I missed stating a fact.  To get the needed instruction set for the da-avx version, it needs the 4XXX or newer machine class (Haswell.)   I think that the startup message on the AVX version explains that -- but if it doesn't start, then you cannot see the startup message!!!   MY MISTAKE about the documentation.  I commiserate with you about the slowness of the da-win version though -- my laptop, where I do the windows development, is only a dual ATOM!!!   Imagine how damned slow that is!!!   A quad i5 should be pretty good, a dual i5 might be slow, but not as bad as my 2 core ATOM...

* The decoder is NOT fast, and is intended to be run once (or a few short times to tune in the right sound), and not for normal listening. It is CLUNKY, very very CLUNKY.   The thing is doing HUGE amounts of math, especially in the --xtra, --xp and --xpp modes, doing all kinds of sideband twisting to hide away the distortion.  If you are getting a little faster than realtime, that is kind of what I expect.   If you have an 8 core machine (I wish!!!), then even the super high quality decodes should happen pretty quickly.

Let me double check to see if there is a real advantage to using the instructions on the 4XXX or newer versus the 3XXX machines.  I seem to remember it might have had something to do with the register widths for the SIMD.   The SIMD is critical for the DHNRDS to work very well -- and that is one major reason why the da-win version is so damned slow.  If there isn't an advantage, then it might be worthwhile to remove whatever thing I am doing to force the 4XXX level machines or newer.   Even an in-between version shouldn't be very hard -- but those wide, 256 bit registers are critical for the performance.  The DHNRDS runs over 95% of the time in SIMD instructions...

If you use --basic mode, you should be able to get a little better than realtime, maybe even with --normal mode.   The decoder will use up to about 8-10 cores, but works okay with 4 cores.   On my 4 core/8 thread  haswell, I get about 3X realtime on --basic mode, about 2X realtime on --normal mode, and it only loads about 1 core total worth of CPU.   For the --xp type mode, where the quality is super high, I only get slightly faster than realtime, but can realtime play at --xpp mode without any glitches.

 It is a blessing in a way that you have an i5, since hyper threading is usually not enabled on those machines.  Hyperthreading and the decoder don't get along very well...  This is because the decoder will saturate the CPU with just one thread, and default scheduling causes a major slowdown.   I have an --affinity switch for linux that lines up the CPU/core usage more ideally, but I didn't see an EASY way to line up the CPUs on windows because I couldn't find an easy way to find the hyperthread/CPU mapping.  I am definitely not a windows expert.

John

Okay, options to use -- --basic mode if you have CPU speed issues.  It is still better than a real DolbyA.   I am in the midst of putting together a new version -- it will plug right into what you are doing now.  When I get this new version out, I'll send along some more detailed instructions.

Right now, after some feedback from a good listener, I think that we have the MOST BEAUTIFUL ABBA decodes now -- clean and smooth, but clear!!!   When it is ready, I'll privately send you a pointer, but here are some early examples that just came off the  presses.  The version that I am testing right now, for these examples is the version coming out tomorrow.  You can definitely get by with just replacing the da-win or da-avx program files without changing anything else for the upgrade (hopefully tomorrow.)

Here are the smooth ABBA decodes, and you or anyone else using the decoder can get these kinds of results (now remember, this is ABBA):

Because they are public, these must be snippets:

https://www.dropbox.com/sh/uebmc1f8tjgle9n/AADEl8hpLhMRfVPH7BOvnafoa?dl=0

Silly me -- I made a mistake with the snippets previously -- kept thinking that I was properly updating them, and I was grabbing the wrong versions instead.  I seem to have done that a few times in other situations, gotta be more careful.

These snippets now will sound how I expected...  I'll be doing some more tests later on and will make some snippets availalble if they are fun enough by themselves...

https://www.dropbox.com/sh/uebmc1f8tjgle9n/AADEl8hpLhMRfVPH7BOvnafoa?dl=0

The decoder update will be coming in about 14Hrs from posting time.

John

This note is about the decoder speed -- if the decoder being 'slow' is a major impediment for you to  use it, I am willing to do some things to speed it up, but I can only speed up the --basic mode, and maybe the --normal modes.  I haven't focused on speed, but have focused purely on quality....   There are some possibilities for perhaps 20-50% speed up without quality loss.  It will take some time, and I have been focusing on archival quality decoding where one is lucky to barely get realtime decoding even on a fast 4 core machine.   Realtime is easy on 8 core machines for the highest quality modes, but not everyone has one of those yet.

So -- if speed is REALLY important, and would make it easier for  you to use, then I am willing to spend the days to speed it up.  Possibly when speeding up that section of the code, I might be able to start splitting off the 'simple mode' stuff so that a plug-in developer could port it.   Unfortunately, there is ZERO way that any kind of Python, Java or Javascript can really run the decoder code very efficiently.  The decoder really does need the big/fat SIMD instructions to run quickly, and takes advantage of the C++17 standard and good implementation of SIMD and vector capabilities.  (For the super-intensive SIMD code, Clang C++ is best, gcc C++ is good, Intel C++ is quirky, but functional.)  The last time that I checked, the code can be built for ARM Neon machines, but I do use inline ASM for Intel machines.

Anyway -- I know that they decoder is a little (a lot) slow, but it is really doing a LOT of work.  It can be sped up a little though..

John

I'm always going go to an output file, so speed, while nice is pretty secondary. I'm retired, so a script taking 10 more minutes to process a whole CD's worth of music is not a burden. I'm happy if you use the time you can devote to this to output quality.

33 minutes ago, Skip Pack said:

I'm always going go to an output file, so speed, while nice is pretty secondary. I'm retired, so a script taking 10 more minutes to process a whole CD's worth of music is not a burden. I'm happy if you use the time you can devote to this to output quality.

Yea -- I am kind of in a forced retirement -- got sick, and then when trying to get better -then I hit the magic age anyway.  I'll probably go back to work again, in an advisory/support type role.  I don't want the rat race anymore...

Since you show a lot of interest, I am going to send you private message about some things...

John

The decoder update might (will) be delayed another day.  I have been working too hard in the last day, and need to rest.  I am probably using EXACTLY what is going to be released, but I am so tired....