Decoder for material with latent DolbyA encoding

[John Dyson]

This problem is more common than one might thing. Ever notice the slightly woody midrange, or swishy high end on a lot of recordings? This would be especially true for material created before 1994. The reason is that the material is often NOT decoded DolbyA from the tape, but instead has been EQed. EQed DolbyA, what does it sound like? Take the HDtracks release of the Carpenters singles, any of the many album releases from CDS up to the middle 1990s'. Many are pure DolbyA with EQ. Unfortunately, the loudness wars further distorted the recordings, and they are probably impossible to perfectly recover.

I have a 100% working DolbyA decoder (no slippery plug-ins that mostly just EQ, but a real decoder.) The DolbyA decoder is semi-commercial, but the FeralA (the EQed DolbyA) decoder is free to use. The decoder works, but is ugly to use because it is command line. Also, I am NOT a windows programmer and do NOT do GUI programs. However, the basics and decoding internals of the program are *perfect*. The 'FeralA' stuff is more experimental, as it is a bunch of filters and stereo image manipulations that undo the encoding on the consumer material. Here is a note that I sent on one of my 'home' forums... The key is, this is free to use for consumers and pros alike, but the pure DolbyA decoding wont' work without a license file. The FeralA (with all of the extra filters) work out of the box. Well, if you can stand command line operations . I have numerous examples that demonstrate the FeralA form. Below is a list of recordings simply residing in my collection -- much of the time, when given test cases, the material IS compressed by DolbyA instead of decoded.
Olivia Newton John, EMI 48 early singles

Queen Greatest Hits, Linda Ronstadt 1977 CD, Linda Ronstadt Hits, Herb Alpert & Tijuana Brass, Dionne Warwick hits , Carpenters 1970 CD

Sergio Mendes & Brasil'66, Carpenters 1971 CD, Carpenters 1973 CD, Carpenters HDtracks download,

ABBA ABBA CD, ABBA SuperTrouper CD, ABBA The Album CD, ABBA The Visitors CD, ABBA Voulez Vous CD

ABBA Arrival CD, ABBA Ring Ring CD, Carpenters 1972 CD

Add the --classical switch
London Philharmonic Orchestra, 50 Classical hit

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

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 update the code as I find bugs (hopefully none or minor.) The base decoder that decodes DolbyA material is *perfect*, but the FeralA stuff is still somewhat green. The FA decoder went from a complex monstrosity, and with a bit of sanity injected into the effort, the filters actually became pretty simple.

John

 

[John Dyson]

The DHNRDS DA was just upgraded, I added some more usage information. The old decoding examples are gone, but more can easily be created -- there have been some major improvements in the corrective EQ to recover the original DolbyA from consumer recordings. Below is an URL for the latest decoder (you want the 1.2.0K version), along with some usage info.
Sometimes, people want objective data that shows 'how good' something like the DA/FA decoder is -- I am sure that some might be thinking 'snake oil' -- this stuff is NOT snake oil!!!!

I have attached two .png files, one is from a properly decoded version of 'Crime of the Century' 'School' from MFSL. As consumer CDs go, it is pretty good quality and fairly accurate. Then, compare with the .png from a decode using the DHNRDS from an early issue of the same material on CD. This CD was the standard DolbyA 'Feral', quickie EQed version of the material like most CDs, but then properly corrected and decoded using the DHNRDS.

Take a look at the noticeably greater detail, less background noise, and less 'fog' or 'fuzz' around the spectral energy spikes. Both spectrograms were done from the same bit depth and sample rate. Also, the DHNRDS version is a little lower quality than the actual 88.2k/FP output -- the 44.1k/16bit down converted version shows a little more background noise, and is inferior to some extent.
(I'll probably add snippets from the two versions of 'School' from 'Crime of the Century', but the short snippets aren't really impressive like the entire recording.)

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

Spectrograms:
MFSL version at 44.1k/16bits, DHNRDS version at 44.1k/16bits, and DHNRDS version at 88.2k/FP


John

 

[John Dyson]

BTW -- I did add the examples, but also, I wanted to clarify that the MFSL version of 'Crime of the Century' is one of the few PROPERLY decoded CDs as most have the latent compression. As normal CD quality goes, the MFSL version is very, very good. The reason why the DHNRDS version is a little (I believe a lot) better is because the DHNRDS version didn't use the DolbyA. As I have explained elsewhere, there are some defects in the DolbyA decoding mechanism, even though the encoding mechanism is as clean as expected given the HW design. The decoding design has extra delays in the feedback loop that cause an imprecision along with another layer of modulation effects on top of the encoding mechanism...
The examples are mp3, just good enough to be able to hear many of the differences and play realtime on Dropbox.

Clarifying: the DHNRDS totally replaces a DolbyA for decoding only, and also has the necessary filter banks (optional) that can recover the DolbyA signal from many consumer CD recordings as I have listed elsewhere. (literally 1000's of CDs, not just a few.)

John

 

[Wes]

Thanks for your work on this!

Any way to get a decoded version of these yet? esp. Linda Ronstadt...

 

[John Dyson]

Thanks for your work on this!

Any way to get a decoded version of these yet? esp. Linda Ronstadt...

I'll send you a PM. I was just looking for something else to test-decode this version... I'll let you know when it is done, probably an Hr or two.
(I haven't done PMs on this forum yet -- so, we'll figure it out ).
I'll see if which album sounds best and give it a try again.

John

 

[Blumlein 88]

I've gotten some of John's work on Audiophile Style, and these are real improvements in how enjoyable these are. Give them a try if you are much interested. Very interesting the differences in some of these.

@John Dyson do you happen to know how the MFSL version of "Breakfast in America" is?

BTW, PM's are called Conversations on this forum software. Just click on a person's username, and one choice is Start Conversation. Pretty much like PM's otherwise. And glad to see you posting here.

 

[John Dyson]

I've gotten some of John's work on Audiophile Style, and these are real improvements in how enjoyable these are. Give them a try if you are much interested. Very interesting the differences in some of these.

@John Dyson do you happen to know how the MFSL version of "Breakfast in America" is?

BTW, PM's are called Conversations on this forum software. Just click on a person's username, and one choice is Start Conversation. Pretty much like PM's otherwise. And glad to see you posting here.

I don't have a copy of the MFSL 'Breakfast', but of course the distribution directory for the DHNRDS FA does evidence that I have a copy of the MFSL Crime. The MFSL Crime IS good, just has those DolbyA decoding artefacts -- it is definitely more listenable than the feralA copies that one would normally purchase. I have noticed that MFSL at least sometimes does decode their recordings -- I have to give them credit for doing their job correctly.

I'll send you a 'Conversation' message in a minute. Thanks for the nice comments!!!

John

 

[John Dyson]

I just made a new release of the decoder, works better, easier and the --play command works on Windows. There are two realtime play options available, one that uses SOX and one that uses a simple little adjunct program.
The previous demos are gone, but there have been major improvements since then. The decoder is on the final polishing phase, as perfection is coming close. NO matter what, even when not perfect, getting rid of the 'woody' sound and HF compression is nice.

Here is a pointer to the forum where there is a pointer to the location along with some helpful info. Usage of the decoder is free, and it really does work. The 'avx' version though really needs AVX2 like a Haswell, Zen or Excavator. The 'win' version is slow because it is limited to SSE3 and the program is very highly optimized with SIMD code.

https://audiophilestyle.com/forums/topic/58668-ferala-decoder-free-to-use/

John

 

[maverickronin]

The 'avx' version though really needs AVX2

AVX. The space heater instruction set.

Seriously though, it's cool that you put so much work into this. Not sure if I'll ever need it, but I stashed a copy away just in case. I'm sure this exactly what someone else need though.

 

[mansr]

I just made a new release of the decoder, works better, easier and the --play command works on Windows. There are two realtime play options available, one that uses SOX and one that uses a simple little adjunct program.
The previous demos are gone, but there have been major improvements since then. The decoder is on the final polishing phase, as perfection is coming close. NO matter what, even when not perfect, getting rid of the 'woody' sound and HF compression is nice.

Here is a pointer to the forum where there is a pointer to the location along with some helpful info. Usage of the decoder is free, and it really does work. The 'avx' version though really needs AVX2 like a Haswell, Zen or Excavator. The 'win' version is slow because it is limited to SSE3 and the program is very highly optimized with SIMD code.

https://audiophilestyle.com/forums/topic/58668-ferala-decoder-free-to-use/

Could you post a direct link for those of us who are banned from Audiophool Stool?

 

[John Dyson]

Here is the link, but there is a lot of context on the forum... Below are some postings from the other forum. Note that I am doing a new release in about 2 days, once I feel a little better -- but this one is okay esp if you add the '--fbh=2750 --fbq=0.7071' switches to the command line. After the link, here are some of the postings, plus read the text files. Message me or post a message on the forum as appropriate if you have troubles. It is NOT for the faint of heart at all -- but once it is figured out, it works pretty well... I am trying to say -- if you try it, be patient if you have troubles. I am a very bare bones, gut level programmer, and do NOT do UI stuff very well...

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

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 effectbug fixing -- it is really entertaining to see how efficient the clang++ compiler is, producing really good SIMD code... The clang compiler is AMAZING.

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

---------------------------------------------------Another post about input file formats, using CD files:


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.

----------------------------------------------- Another comment about input file quality:

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

----------------------------------------------- About Using with SOX, mostly some tricks on getting SOX to work better on Windows.

Oh -- the glitches -- sorry I didn't provide more complete info last night -- I was barely awake . It will stil be a few more hours before I write more about using the decoder, but it looks like you are doing great so far.. I am SO glad that both version of play worked, my Windows expertise has rotted away over the last 20yrs .


Okay, about sox... The 'trick' is that SOX doesn't know which driver to use. At first, as you know, it seems like Windows SOX almost doesn't even support a 'play' feature. Note that I am not directly using a play command when I execute the sox command from the decoder, but I use the exact raw sox command as follows (note the paranoia in setting the I/O mode, might not be needed);

* actually, instead of 'sox', I am using the full path, so the sox must be installed in the normal place for the version as follows from the source code

static const char *soxlocation = "c:\\Program Files (x86)\\sox-14-4-2\\sox.exe";


or for humans:


c:\Program Files (x86)\sox-14-4-2\sox.exe

pipe input | sox -q --type=wav - --bits=16 -twaveaudio rate 44100
or
pipe input | sox -q --type=wav - --bits=16 -twaveaudio <id> rate 44100


(<id> is an index like 0,1,2,3,4 which points to the desired output device)

A more normal use of sox, just to play a file, one would do:

sox filename.wav -twaveaudio

the above should work, and shouldn't really need to set the bits modes or the data rate. I set the data rate above because the decoder writes at 88.2k/floating point, and I wasn't sure if all versions of windows drivers supported that mode.

Another mod that might be helpful, instead of '-twaveaudio', you might need '-t waveaudio' (note the space.)

Another oddity -- did you notice that I specified the INPUT data type from the pipeline? Normally, on Unix, one doesn't need to specify the input stream type as autodection works okay on input streams. However, on Windows, the automatic type detection seems to fail. SO, I forced the input type to be '--type=wav'. The type detection seems to work okay when using a normal file instead of '-' or pipe for the input file.


About how I run 'sox' indirectly from the DHNRDS DA... Basically, I stay in the POSIX land instead of using direct Windows calls. I cannot use the 'system(3)' call because 'system(3)' calls the shell, but most people aren't going to have a POSIX/cygwin 'bash' program on their systems, so I get deeper into the POSIX nitty/gritty and do the old fork(2)/execl(2) thing and manually set up the call to 'sox'. The aoplay.exe program is called in a similar way.


The data stream when using SOX is a standard .wav file, but on aoplay, since I didn't want to encumber my .wav file processing subrotines (however crappy my subroutines are), I simply created a stream that is led with a 'magic number', then a data rate and then an extra data item for the future. The rest of the stream are the audio bytes encoded as 24 bit signed data... Basically, the aoplay.exe uses 24bit signed .wav data, but without a normal .wav header.

 

[Dimitri]

I am a very bare bones, gut level programmer, and do NOT do UI stuff very well

You say that as if it's a bad thing
When your car mechanic is a better detailer than mechanic, you need a new mechanic.

 

[John Dyson]

I just reread the instructions, and want to amend the early examples as posted -- I modified the program to work more easily... However, there are no defaults on the --fa switch -- by mistake. SO, instaed of just --fa, use --fa=2. I'll eventually modify the program (again) to have a reasonable default. When you use an --fa=2 switch, that is the most common 6000Hz 1pole rollofff that counteracts the 1 pole 6kHz boost that is apparently used.
Also, the current version of the decoder has another suboptimal filter, but this second change is less important... Add the following pairs of switches which will clairfy vocals especially well ' --fbh=2750 --fbq=0.7071'. Basically this replaces a gain shelving boost of 9dB at 3kHz/Q=0.50 with a 9dB at 2.75kHz/Q=0.7071. The original boost is okay, but some material was sometimes a little 'buried' sounding, and since I couldn't find a specification for the EQ being used, I had to reverse engineer it by careful listening. (VERY VERY careful listening, that is.) It is very tricky to avoid doing what 'sounds good per my taste' instead of 'sounds correct', which are sometimes two different goals. The deocder is written to be able to adapt to almost any kind of EQ against standard DolbyA recordings -- but my goal is that the standard settings, perhaps with only one or two parameters is all that should be needed in the majority of cases.

So, to summarize my long blathering --

1) relplace the usage of --fa with --fa=2 in the original examples above (the online downloaded docs are correct)
2) add --fbh=2750 --fbq=0.7071, only for slightly more accurate decoding

In the next few days, the new release will have these two things fixed, and all that will need to change is slipping in the new .exe file -- no re-install or re-config will be actually needed.

John

 

[John Dyson]

Wow -- hold the presses... New version coming in about 2-3days, maybe more likely end of week. Have lots of tests to do -- a frustrating problem with the stereo image is vastly improved. I'll make some snippet demos in a few days. Prevoius versions of the decoder were an embarassment in comparison. Also, there is a minor improvement in lower midrange IMD, almost like the material had a special EQ that caused some distortion.

These results are incredible -- almost like 'quad' sound in comparsion to the CDs normally sound. I am NOT claiming any magic, but just a progressive improvement in the decoder.
Figure on the 4th of Apr at the latest, but I am hoping sooner. The reason for the multi-day delay is that the results are so astounding that I need to start from scratch on testing...

John

 

[John Dyson]

Here are some snippets from the 1977 Linda Ronstadt album. Someone on this forum asked me privately about Linda Ronstadt, and I didn't really do a full quality job until now. I think that the calibration is still a little too high a value, causing a SMALL amount of confusion in the sibilance, but other than that -- the ambiance is stable all the way down to the background -- no audible IMD. These WILL sound different than almost any other recording that is available... Sorry that they must be snippets only!!!

Add on: even though mp3 doesn't do these justice, the dropbox player is worse. There is a phasing in the sound with dropbox, and these recordings push the mp3 very, very hard.

https://www.dropbox.com/sh/o2dx4goe5qgx6dh/AADTYGSw6VaSyHoARquyXgixa?dl=0

 

[John Dyson]

I just released a profoundly improved version of the FA EQ and then subsequent DolbyA decoder for consumer CDs. However, a user just asked for an additional feature vis-a-vis the .wav file metadata. I plan to do another release by Friday, but with the new .wav file capabilities.

This new version is almost infinitely easier to use, and errors on the decoding settings are less punishing -- that is, set-up errors are much more forgiving.

I have also figured out a possible commercial method to benefit from the decoder, allowing remastering without IP encumberment. That would definitely meet my goal of 'improving the music', but not getting the end-user involved with all of the decoding problems.

Friday will be the day (I hope) for the next release.

John

 

[John Dyson]

V1.4.1A of the FA decoder is ready. It can also decode DolbyA files with a separate (for asking)
license file. (DolbyA decoding is part of the FA decoding process, but on FA, there is a lot
of 'pre-processing' to undo the FeralA equalization damage on a lot of CDs and downloads.)

It sounds really good, but as you know, I do botch things. I'll fix last minute bugs as quickly as I can, and try to answer questions as long as I am awake .
(Hope that I didn't upload the source files instead of the binaries ).

First, the .wav file support is a little better. Metadata should be more transparent.
Second, the quality is A LOT better, but with some caveats. The caveats: different decoding parameters are desirable.
Except for bugfixes, I am hoping that the 'decoding engine' is complete. It is very good at avoiding modulation distortions, so good that I don't think that it is possible to be any better. This doesn't mean that the project is 'finished', because there is ALWAYS room for usability improvements.

The Windows V1.4.1A version installs essentially identically to the previous.
For Linux, unpacking the ,txz file produces a V1.4.1A subdir, and the programs reside in that subdir.

After following the paltry install instructions (refer earlier in this forum for Windows), then the fastest way to get started is to read the 'gettingstarted-V1.4X.pdf' file. Then, when you get somewhat comfortable, then try to read the babble in the 'using-1.4X.pdf' file.

I am attaching the 'guides' for really quick reference, but everything (including the 'guides') is in the Dropbox location.

The Windows program file: 'da-release1.4.1A-win-2020-04-21.zip'
The Linux program file: 'da-avx-V1.4.1A-Linux.txz'

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

I own the software, and you have full rights to use or redistribute as much as you want. I'd prefer that when redistributing it -- TELL ME (not required -- I just want to have an idea about how many people using the decoder.)
The difference between knowing that there are two or three users total is really important to me .

The raw/true DolbyA mode itself requires a license file, so unless you use the '--fa' or '--fb' or '--fc' or '--fD' switches, then the decoder will choke without the license file. If you want/need (unlikely), I'll make you a license file so you can do real, undistorted DolbyA decoding. The licensed version shouldn't be redistributed without permission. But, for feralA -- HAVE AT IT!!! Frankly, the FeralA decoding is more sophisticated than DolbyA anyway... .

Please have fun with this -- don't let it be frustrating or be a chore, I'll do what I can to help using the decoder.

John

 

[mansr]

Could you please make a Linux build that doesn't need AVX2?

 

[John Dyson]

Could you please make a Linux build that doesn't need AVX2?

Okay -- I haven't done so for a while, but I'll should be able to make it available by tonight. I even had an ARM NEON version of a very early version a long time ago -- no-one was out there to use it . There is some inline asm to boost the speed, but I do use the same compiler for Windows vs. Linux (Clang++), and there WAS a Linux sse3 version (would run on Atom or i2XXX type processors). Unfortunately, I cannot test runnong a non-AVX2 version on an Atom or i3XXX or earlier AMD machine for Linux. I'll make the version, and HOPEFULLY should work...

John

 

[sergeauckland]

I don't want to derail this thread by asking a question, so apologies if I do.

I don't understand why record companies don't just run their Dolby A encoded material through a real Dolby A decoder. There must the hundreds of these still around. If I understand correctly, they aren't doing that, and just EQ the resulting poor sound. Dolby A decodes correctly provided the correct line-up tone is used to set the levels. Perhaps there's nobody left in studios who knows what a line-up tape is!

If so, the recording industry is in a far worse place than ever I thought it was, and that's pretty low!

Sorry for the intrusion, but I find all this fascinating.

S.