John Dyson Posted April 6, 2020 Author Share Posted April 6, 2020 4 hours ago, lucretius said: For previous versions, you said the --tone value will be between -12.80 and -12.95. Why did this change? The change happened because of some EQ filtering changes. The relative levels changed in some areas -- it was actually a bugfix. There should be no more such changes now -- this is the first time I revisted the basic EQ mechanism in a LONG time. This change resulted in the first PROFOUND improvement in a few months. The basic filtering structure has been simplified -- now using the bare minimal set of needed filters for the most precise decoding. The gain vs frequency vs time changed... Instead of adding a compensation layer in where the calibration would be kept the same, I just decided that since this is still early in the game, and the EQ is now more correct/flat over the frequency range -- it is best to allow the change. Now, the calibration levels are more close to what would be expected for a tape... A -12.85dB calibration tone is a little tight on headroom, but a -13.30 calibration tone is a little more realistic for reasonable headroom. So, basically a restructuring of the midrange EQ and the removal of a layer in the 3k->20+kHz range EQ -- not needed, the optimum input levels changed. Resulting from the fix, we all SHOULD notice less 'grinding' between the 80->3k MF band & the two HF bands (3k-20+k and 9k-20+k). * When I use the term 'grinding' -- when the changing gains in the EQ transition region are not 100% accurate, then there is a kind of distortion created. That distortion has now been SIGNIFICANTLY reduced -- already better than a DolbyA running in its native mode for OTHER reasons - this EQ improvement added yet another layer of improvement. True DolbyA HW 'grinds' alot all by itself - but the DHNRDS DA does not. I expect no more 'calibration changes' at this point. The 'distortion' decrease has been so profound that the new simplified filters are much more pleasurable to use -- because the results are simply more 'pretty'. (When working with this stuff day-in and day-out, when distortions like what a DolbyA produces are mitigated -- it can be a very 'beautiful' feeling. It is like a 'grinding' that you didn't hear before -- JUST GOES AWAY.) I truly HATE subjective adjustment - but this is damned tricky, totally undocumented, and no scheme available to measure the errors. * One more item of note -- the current EQ configuration is more accurate for most FeralA situations. There are two layers usage expertise providing two subtle levels of availabe quality. These are based on the EQ accuracy -- the default scheme using --fa=0,1,2,3,4 and --fa=classicalN can be made to work beautifully most of the time, however there are recordings that are still not 100% optimum. This is where the --fa=spcN modes were added. These modes are more ideal for certain recordings. With these three *already described* sets of generic modes, a VERY HIGH quality result can be obtained by far most of the time - llike 95% of my collection. (Actually, I believe it works for ALL of my CD/download collection -- but I don't like making the claim -- there are always outlyers.) If you want even more PERFECT decodes - not just REALLY REALLY GOOD decodes, there is another layer of EQ fine-tuning, but it is NOT outside of the three level scheme that I speak of, but is an adjunct... These nw EQ changes have allowed all three normal usage levels, and the SUPER HIGH quality modifications of those levels to be SO MUCH SIMPLER to use. Once the basic three layer scheme is understood and practiced, the step beyond that is pretty easy to comprehend. I didn't want to expose that *dirty secret* yet to avoid complexity and give me time to become better practiced at it. But importantly, any example that I have given about this new EQ redo has used the 'generic' scheme as I described in the usage document. As a user who is teaching me how to explain the decoders use -- you have the tools to do anything that I have demoed so far. *All of the 'quality' is already available in the decoder -- it is just not needed unless trying to do almost 'forensic' level decoding that is far beyond anything normally available, including the VERY BEST MFSL stuff. I will be describingthe fine tuning, once I can figure out a good way to do explain it -- also I don't want to confuse the simple usage that already gives pretty darned amazing results with the relatively simple and consistent switches. I am not hiding the details -- they are just a 'fine tuning' of the existing settings. JUST this evening/morning, I have been experimenting with the more precsion decoding, and getting interesting and productive results. I am preparing myself to LEARN be able to explain how to use the FA decoder in its full glory. BUT, being totally straight forward, in the two examples that I gave in the previous post -- they were done with the GENERIC modes that I have documented so far. As documented, the decoder sounds REALLY GOOD -- but can sometimes be made to sound even better. Without the DA mode decoder layer being so time-domain precise WRT distortion requirements -- any quality provided by the current FA equalization scheme would be otherwise superfluous. Dirty secret -- the FA stuff is NOT well defined and not consistent between distributors. Decoding FA would normally be deemed 'impossible', but the DolbyA compatible decoder was previously deemed impossible do do in SW also -- I like to do difficult things :-). 2yrs ago, my project partner said to expect that the distributors do really strange things to recordings -- and I have verified that he is correct... Sorry to say... John lucretius 1 Link to comment
John Dyson Posted April 6, 2020 Author Share Posted April 6, 2020 6 hours ago, lucretius said: @John Dyson Tried v.1.3.1B (windows). Everything seems OK so far but I am still having trouble with the SoX pipes -- I run this: sox infile.flac --type=wav - | da-avx --fa=2 --tone=-12.90 | sox - outfile.flac and I get this error: sox FAIL formats: can't open input `-': WAVE chunk fmt not found The same command works fine in Linux Mint so maybe this is a Windows issue? Cheers! Got an idea -- the error printed is ignored by most versions of SOX that I know of. I suggest using --info=2 to see if decoding progress is being made -- just the error might be worrying that it isn't really working?!?!?! I haven't had a problem with programs totally rejecting a .wav file without 'fmt'. I'll add the 'fmt' block if something is rejecting the 'file' -- but it is one of those things that shouldn't really be necessary -- all of the info is already in the file header without it. I can actually add the fmt block pretty easily -- it is just that early-on, there were a lot of more profound problems to deal with... I'll add 'fmt' if the missing block IS really causing trouble and cut a new release for the fix. (There are two knarly/dirty pieces of the code -- one is the input band filters --doing the filters 'correctly' was impossible -- and the other is the .wav file handling... It reminds me of the incomprhensible assembly code days, but I have not excuse for such errant coding techniques today :-)). Also, if this is a case where SOX doesn't know that the decoder is providing a .wav file through the pipe, then maybe try this command line instead (with the changes that are typical for the new version of the decoder -- and enabling the second-by-second progress/gain indicator): >>>> sox infile.flac --type=wav - | da-avx --fa=2 --tone=-13.30 --info=2 | sox --type=wav - outfile.flac (note adding --type=wav just before the '-' in the 2nd sox commmand) If the output file is gibberish, it might be an inabillity to sense the sample rate (I actually experienced that on SOX Windows in other situations), so try this also -- but I hope that this isn't needed: >>>> sox infile.flac --type=wav - | da-avx --fa=2 --tone=-13.30 --info=2 | sox --type=wav --rate=88.2k - outfile.flac (added '--rate=88.2k' right after the '--type=wav' in the 2nd sox command) * Off the top -- I forget what is in the 'fmt' block, but I wonder if that is the reason why SOX transiently has troubles reading the .wav files in pipes? If the 'solutions' above don't resolve anything, I'll cut a release tomorrow with 'fmt' added and any other needed changes. The FA mode is REALLY frozen now -- it now meets my expectations, so anything changed should be bugfixes. John Link to comment
lucretius Posted April 6, 2020 Share Posted April 6, 2020 2 hours ago, John Dyson said: Got an idea -- the error printed is ignored by most versions of SOX that I know of. I suggest using --info=2 to see if decoding progress is being made -- just the error might be worrying that it isn't really working?!?!?! I haven't had a problem with programs totally rejecting a .wav file without 'fmt'. I'll add the 'fmt' block if something is rejecting the 'file' -- but it is one of those things that shouldn't really be necessary -- all of the info is already in the file header without it. I can actually add the fmt block pretty easily -- it is just that early-on, there were a lot of more profound problems to deal with... I'll add 'fmt' if the missing block IS really causing trouble and cut a new release for the fix. (There are two knarly/dirty pieces of the code -- one is the input band filters --doing the filters 'correctly' was impossible -- and the other is the .wav file handling... It reminds me of the incomprhensible assembly code days, but I have not excuse for such errant coding techniques today :-)). Also, if this is a case where SOX doesn't know that the decoder is providing a .wav file through the pipe, then maybe try this command line instead (with the changes that are typical for the new version of the decoder -- and enabling the second-by-second progress/gain indicator): >>>> sox infile.flac --type=wav - | da-avx --fa=2 --tone=-13.30 --info=2 | sox --type=wav - outfile.flac (note adding --type=wav just before the '-' in the 2nd sox commmand) If the output file is gibberish, it might be an inabillity to sense the sample rate (I actually experienced that on SOX Windows in other situations), so try this also -- but I hope that this isn't needed: >>>> sox infile.flac --type=wav - | da-avx --fa=2 --tone=-13.30 --info=2 | sox --type=wav --rate=88.2k - outfile.flac (added '--rate=88.2k' right after the '--type=wav' in the 2nd sox command) * Off the top -- I forget what is in the 'fmt' block, but I wonder if that is the reason why SOX transiently has troubles reading the .wav files in pipes? If the 'solutions' above don't resolve anything, I'll cut a release tomorrow with 'fmt' added and any other needed changes. The FA mode is REALLY frozen now -- it now meets my expectations, so anything changed should be bugfixes. John Simply adding the --info=2 switch did not work -- input: sox infile.flac --type=wav - | da-avx --fa=2 --tone=-12.90 –info=2 | sox - outfile.flac output: sox FAIL formats: can't open input `-': WAVE chunk fmt not found However, I did note that the decoder was working. OTH, adding --type=wav just before the '-' in the 2nd sox command did work! input: sox infile.flac --type=wav - | da-avx --fa=2 --tone=-13.30 --info=2 | sox --type=wav - outfile.flac output: Finished 'outfile.flac' played just fine in JRiver MC. Thank you. One thing I did notice was that the metadata and album art embedded in 'infile.flac' was not retained in 'outfile.flac'. Would there be anyway to retain this metadata, etc.? mQa is dead! Link to comment
lucretius Posted April 6, 2020 Share Posted April 6, 2020 15 hours ago, John Dyson said: The --tone=-xx.xx values might seem to require 'precision', but really do not. If the number is within 0.02, there is almost never ANY difference in sound. Also, the range of settnigs on non-normalized CDs is now usually within about -13.25 to -13.40... Even the max or min in this range still results in typically 'good' results. By 'min' and 'max' do you mean -13.25 and -13.40, respectively? mQa is dead! Link to comment
John Dyson Posted April 6, 2020 Author Share Posted April 6, 2020 19 minutes ago, lucretius said: By 'min' and 'max' do you mean -13.25 and -13.40, respectively? Actually the opposite -- -13.25 is larger than -13.40... It mucks me up also, because intuitively the numbers seem opposite because they are negative. But, basically to explain, at HIGHER threshold levels (like -12dB) , the HF gain (and gains in general) will decrease. At LOWER threshold levels (like -14dB) the gains in general will increase. On DolbyA decoding, the gain is on a 'hinge' which is the calibration level. Signal levels ABOVE the 'hinge' will be close to 0dB (except at MF, where the threshold is 10dB or so lower), below the 'hinge' level, the gain will tend to decrease at approx 1dB for every 1dB level change down to a min gain of -10dB at up to 9kHz and -15dB at 20kHz. This 1dB gain change for a 1dB level change effects an APPROX 1:2 dB level expansion. John Link to comment
John Dyson Posted April 6, 2020 Author Share Posted April 6, 2020 49 minutes ago, lucretius said: Simply adding the --info=2 switch did not work -- input: sox infile.flac --type=wav - | da-avx --fa=2 --tone=-12.90 –info=2 | sox - outfile.flac output: sox FAIL formats: can't open input `-': WAVE chunk fmt not found However, I did note that the decoder was working. OTH, adding --type=wav just before the '-' in the 2nd sox command did work! input: sox infile.flac --type=wav - | da-avx --fa=2 --tone=-13.30 --info=2 | sox --type=wav - outfile.flac output: Finished 'outfile.flac' played just fine in JRiver MC. Thank you. One thing I did notice was that the metadata and album art embedded in 'infile.flac' was not retained in 'outfile.flac'. Would there be anyway to retain this metadata, etc.? Oh yeah, the conversion of the flac metadata is incomplete in SOX. When I produce flac files, even though the DA decoder makes its own metadata, I have to manually re-create some metadata for flac files. Much of it is about SOX. On the other hand DA decoder maintains SOME of the metadata, esp the BEXT items for professional purposes. It will append to already existent BEXT data, or create its own. Other metadata, some of it gets thrown away. If you think that is a major deal -- I might be able to add some support to maintain more of it. When originally doing the DA decoder, I was focused on the BEXT stuff (it needs special handling), and ignored the other stuff -- possibly wrongly. I truly forget, and will look into it. It shouldn't be too awful hard to add some other data items. As I wrote before, the .wav file handling is knarly. :-). John Link to comment
lucretius Posted April 6, 2020 Share Posted April 6, 2020 31 minutes ago, John Dyson said: Oh yeah, the conversion of the flac metadata is incomplete in SOX. When I produce flac files, even though the DA decoder makes its own metadata, I have to manually re-create some metadata for flac files. Much of it is about SOX. On the other hand DA decoder maintains SOME of the metadata, esp the BEXT items for professional purposes. It will append to already existent BEXT data, or create its own. Other metadata, some of it gets thrown away. If you think that is a major deal -- I might be able to add some support to maintain more of it. When originally doing the DA decoder, I was focused on the BEXT stuff (it needs special handling), and ignored the other stuff -- possibly wrongly. I truly forget, and will look into it. It shouldn't be too awful hard to add some other data items. As I wrote before, the .wav file handling is knarly. :-). John Maintaining metadata is a big deal -- I have a large "catalog" and each track has quite a bit of metadata -- having to recreate the metadata would be a major pain in the neck. (I rely on the metadata for various things including the operation of Roon, the specific source of the master, info on references to online databases, info on composers/songwriters, performers, production personnel, etc.) To avoid SoX, I ran the following: input: da-avx --input=infile.wav --output=outfile.wav --info=2 --fa --fgh2 --tone=-13.30 --basic I checked the output file ('outfile.wav') and most of the metadata (and album art) was missing with the exception of a bit of BEXT stuff. If you're interested, I could send you a wav file (or a sample of wav files) with the metadata. I could also send the flac files if you think that would be better. Thank you! mQa is dead! Link to comment
lucretius Posted April 6, 2020 Share Posted April 6, 2020 42 minutes ago, John Dyson said: Actually the opposite -- -13.25 is larger than -13.40... It mucks me up also, because intuitively the numbers seem opposite because they are negative. But, basically to explain, at HIGHER threshold levels (like -12dB) , the HF gain (and gains in general) will decrease. At LOWER threshold levels (like -14dB) the gains in general will increase. On DolbyA decoding, the gain is on a 'hinge' which is the calibration level. Signal levels ABOVE the 'hinge' will be close to 0dB (except at MF, where the threshold is 10dB or so lower), below the 'hinge' level, the gain will tend to decrease at approx 1dB for every 1dB level change down to a min gain of -10dB at up to 9kHz and -15dB at 20kHz. This 1dB gain change for a 1dB level change effects an APPROX 1:2 dB level expansion. John Is the default (without invoking the switch) --tone value = -13.30? Thanks! mQa is dead! Link to comment
lucretius Posted April 6, 2020 Share Posted April 6, 2020 @John Dyson I do understand the need for wav files and BEXT formats, etc, since the decoding tool must serve the professionals. Nonetheless, if it were possible to eliminate the necessity of having to feed the decoder with proprietary wav files and instead also allowed it to operate directly on (non-proprietary) flac files, that would be just wonderful! I know, I'm dreaming ... mQa is dead! Link to comment
John Dyson Posted April 6, 2020 Author Share Posted April 6, 2020 33 minutes ago, lucretius said: Is the default (without invoking the switch) --tone value = -13.30? Thanks! Yea, the default is -13.30, but probably should be -13.35... The difference isn't much, but is just enough to detect. John Link to comment
John Dyson Posted April 6, 2020 Author Share Posted April 6, 2020 49 minutes ago, lucretius said: Maintaining metadata is a big deal -- I have a large "catalog" and each track has quite a bit of metadata -- having to recreate the metadata would be a major pain in the neck. (I rely on the metadata for various things including the operation of Roon, the specific source of the master, info on references to online databases, info on composers/songwriters, performers, production personnel, etc.) To avoid SoX, I ran the following: input: da-avx --input=infile.wav --output=outfile.wav --info=2 --fa --fgh2 --tone=-13.30 --basic I checked the output file ('outfile.wav') and most of the metadata (and album art) was missing with the exception of a bit of BEXT stuff. If you're interested, I could send you a wav file (or a sample of wav files) with the metadata. I could also send the flac files if you think that would be better. Thank you! Yea -- I'd like an example (one or two variants) of the metadata that you want to keep. Interesting because I didn't even think of it, and it is kind of sad that SOX doesn't support it either. Might take me a few days as the architecture isn't really set up for generic metadata. If I can get an idea of expectations, it might be less of an onerous situation. Like, if it is a specifc kind of metadata, even though it might have lots of instances -- that will give me an idea about what is wanted. I do have some other examples from my own sources (old wav files), but if you want to -- the .wav files would be better... I doubt that I can add .flac support without licensing issues. (I want to keep ownership of my IP, no GPL -- LGPL is okay if it is built-in to the OS, but -- the licensing requires some care.) It might have been easier to use someone elses .wav package, but anything good was licensed in a way that would tie me up a little. Eventually, I plan to give away the source, but not quite ready yet. John Link to comment
lucretius Posted April 6, 2020 Share Posted April 6, 2020 2 hours ago, John Dyson said: Yea -- I'd like an example (one or two variants) of the metadata that you want to keep I sent you a PM. mQa is dead! Link to comment
dean70 Posted April 6, 2020 Share Posted April 6, 2020 6 hours ago, John Dyson said: Oh yeah, the conversion of the flac metadata is incomplete in SOX. When I produce flac files, even though the DA decoder makes its own metadata, I have to manually re-create some metadata for flac files. Much of it is about SOX. On the other hand DA decoder maintains SOME of the metadata, esp the BEXT items for professional purposes. It will append to already existent BEXT data, or create its own. Other metadata, some of it gets thrown away. If you think that is a major deal -- I might be able to add some support to maintain more of it. When originally doing the DA decoder, I was focused on the BEXT stuff (it needs special handling), and ignored the other stuff -- possibly wrongly. I truly forget, and will look into it. It shouldn't be too awful hard to add some other data items. As I wrote before, the .wav file handling is knarly. :-). John Metadata can be exported from the original .flac file using metaflac.exe (part of the flac tools) & imported into the processed flac file. Alchemy Desktop http://www.origen.net.au/Alchemy/ Link to comment
John Dyson Posted April 6, 2020 Author Share Posted April 6, 2020 I plan to make a new version of the decoder ready with the metadata pass through Thursday, Friday at the latest. Trying to have something ready for the weekend. I have been doing test decodes for part of the day today, and have some really clean, simple results. During my mostly rest-day, I have been thinking/worrying about how 'intuitive' the EQ scheme is - that is, not very intuitive. I'll also be documenting the EQ a little better. This is a fine line of complexity vs. clarity -- and I cannot project my ability/inability to think on other people, so I have to guess what kind of docs are needed. (I have a very very bad, damaged short term memory ability -- yet my thinking and long term abilites are crazy sophisticated -- I cannot guess what is easy or difficult for people trying to use this software tool.) GUIDANCE might help me write something that could help users with the decder. If you have any ideas - tell me. Since I do know that most people see things better in pictures, or clear/clean organized text -- I'll really try to use a WYSWYG editor to produce more readable docs -- with some kind of organization. I really do feel that if someone understands the NEED vs what is PROVIDED -- that the deocding EQ choices will be more intuitive. John Link to comment
John Dyson Posted April 7, 2020 Author Share Posted April 7, 2020 A private correspondent on this forum had decided to try to decode a rather difficult recording -- 'Even in the Quietest Moments', and the result of the attempt was a discussion that I think might be helpful for other users of the DHNRDS FA mode of the decoder. The context is that the OP didn't like the results of decoding 'Even in the Quietest Moments', either too harsh with just --fa, and too soft with --fa=2. Note that as of the time of this posting, I haven't gotten a response for this help, but some of this commentary can be VERY HELPFUL for *advanced* decoding of difficult material. Most material DOES NOT require this level of detail!!! The first post is my FIRST response to the OP's troubles (and he is doing good -- just having troubles), the second section is a second response that attempts to give greater technical details: ======================================================================================= FIRST RESPONSE: Ahhh... Even in the Quietest Moments is a real problem because of that horrid 'chorus effect' 'enhancement' in the first cut. I have a raw very early release of the CD -- A&M 394 634-2, which seems to be pure feralA. (FYI) Also, have several other remasters that are all mangled. Just a caveat. Even in the Quietest Moments is an ADVANCED decoding effort -- probably one of my more difficult selections in my own collection. This note, however rambling will talk you through decoding my own copy... Before reading my rambling description -- when you use the --fa=XXX switches, if you use the --fd switch also, it will give a dump about what feralA EQ filters are being used. It might help give you a 'feel' about what is going on. ---------------------------------------- Given the above 'state' of the recording, on my copy -- the raw --fa allows the chorus effect on the first cut to be very edgy and overwhelming, even though the other Supertramp CDs seem okay with just a --fa... Here is my idea... Try this "--tone=-13.37", which decreasing the threshold A SMALL AMOUNT sometimes tames edgieness a little. I suggest that small change will NOT be enough. Next, try this: "--tone=-13.37 --fa=4", which might tame the sound just a little unevenly, but will be improved a lttile. The --fa=4 swich adds in a 12kHz filter before decoding -- that is a relatively small amount. Usually, if a filter is needed, --fa=2 is a good choice, which is 6kHz -- but IS too much for my copy of Supertramp also. On my copy of the CD -- --fa=2 is like a wet blanket. Paradoxically, decreasing the effect of the 12kHz filter, but keeping it at 12kHz seems to be the best improvement for my copy of 'QUIET". The --fa=4, with the 12kHz 1st order LPF is a full LPF all the way up beyond the Nyquist frequency. Instead, that evil enhancement sounds more 'stable' if you stop the LPF at 18kHz... On my copy, I can actually hear both edges/both copies of the enhanced (pseudo-chorus effect) vocal after using the following command: "--tone=-13.37 --fa=4 --fhh4=18000 --normal" Which is a 12kHz LPF, stopping it at 18kHz... YOU MIGHT prefer "--fa=3 --fhh3=18000 --normal" instead, but I feel that the recording MIGHT be filtered a bit too much. It MIGHT be better, but my mastering-hearing is not all that good -- I have poor artistic skills. I try to be careful. Perhaps the '--fa=3 --fhh3=18000" might be better, but if I was demoing to picky audiophiles, I'd tend towards the wider '--tone=13.37 --fa=4 --fhh4=18000' sequence above, but use --xpp also instead of --normal, which kicks in the anti-MD code, but REALLY slows down the decoding. I haven't fully explained using --fhhN in the 'usage' docs, but the more complete document does talk about the '--fhhN' filters cutoffs. Using '--fhhN' is a more 'advanced' usage, but the Supertramp 'QUIET' album is a very advanced, somewhat tricky challenge when compared with most other albums. 'Carly Simon' also has similar enhancement in her vocals, but usually end up sounding smoother. My decoding example is run at the --normal mode, but the --xpp mode will be a little more clean (almost imperceptably better). Attached is a truncated copy of my .flac results. (mp3 tends to filter out the edginess -- not appropriate for this example.) Please let me know if this 'diagnosis' / 'prescription' helps your CD.... If your CD does't sound much like mine -- I can try one of the other exemplars in my collection and try to get good results with those. However, my example comes from a PRISTINE feralA CD. If yours is pristine, but ends up sounding different, then the mastering engineer just might have used different feralA EQ parameters... I can help you if you send me a snippet, and try to get good results as a learning experience for both you and me. =================== SECOND, FOLLOW UP TO FURTHER EXPLAIN THE "MAGIC" about --fa=N, etc.: Clarification why I added the --fhh4=18000. First note that the --fa=4 invokes the filter#4 which is normally a 1st order LPF at 12kHz, just keep on going down -- no stop to the rolloff. When I added the --fhh4 switch, that set the 'stop' for the rolloff on filter #4. Why does that even-out the sound of the vocal enhancement? Tricky stuff, but let me 'splain about DolbyA in detail further down, but basically when increasing the levels SLIGHTLY in the 9k-20+kHz range, it can suppress the 3k-9kHz range just slightly -- DolbyA is like that. The 3k-9kHz range 'fights' the 9kHz-20kHz range because of an inverse decoding relationship. It is also a slight cause for increased distortion during DolbyA decoding, if it is not done correctly. Explaining about the filters: There are 4 normal filters, and a 5th special filter -- don't use it, it will be automatically invoked by using the 'spcN' modes. All 1st order: Filter0: 3kHz LPF FIlter1: 4.5kHz LPF Filter2: 6kHz LPF Filter3: 9kHz LPF Filter4: 12kHz LPF I believe that the Filter0 (3kHz) and Filter1 (4.5kHz) stop the rolloff early, but the rest just keep on rolling off. (You can check it by using the --fd switch.) You can fully control the filters by usign the '--fhN' or '--fhhN' switches, where '--fhN' is the start of the rolloff frequency, and '--fhhN' is the stop of the rolloff. It is usually best to NOT change the '--fhN' value, but you can if you want. I chose the frequencies for a very good reason. However, you JUST MIGHT find a case where a rolloff at 7.5kHz would be better. Then, I'd grab Filter2 or Filter3, and re-configure them with '--fh3=7.5k', and now the Filter3 starts at 7.5k, simple as that. (And yes, using 'k' works.) About DolbyA.... There are two overlapping HF bands, 3kHz to 20+kHz, and 9kHz to 20+kHz. These bands overlap based upon an approx Q=0.450 difference at an 9kHz transition frequency. These bands represent COMPRESSORS in the reverse leg of a feedback loop (theoretically.) (Those compressors in the negative feedback result in an expansion or decoding of the DolbyA material) When the 9k band has more signal strength in the feedback loop, then that will tend to suppress the behavior of the 3kHz to 20kHz band. (Note that I usually name the 3kHz+ band as HF0 and 9kHz+ band as HF1 in my commentary, even in the source code.) Those two expanders have time delays, and there is a critical 'dance' between them on a varying audio signal. If the expanders do not dance a very well choreographed dance, then the result sounds a little distorted. ALL normal DolbyA HW decoder do NOT dance the dance very well. The DHNRDS is excruciatingly accurate and precise in its dance... This is one of the attributes of the DHNRDS that produces more transparent results. So, there is an inverse, suppressive relationship between the HF0 and HF1 bands, and the slight HF1 boost by stopping the filter rolloff at 18kHz actually produces a very subtle suppression of the HF0 band, and also just happens to make the DHNRDS decoder 'dance' more precisely :-). Anyway -- this is both the long story, and longer story. YOU DO NOT NEED TO FULLY UNDERSTAND THIS FOR SIMPLE DECODING -- but 'Even in the Quietest Moments' opend up a can of worms :-). John 01-Give A Little Bit-snippet.flac 9.27 MB · 0 downloads Link to comment
John Dyson Posted April 8, 2020 Author Share Posted April 8, 2020 Everyone -- I am working away on a few minor audible improvements along with the .wav file metadata transparency. I JUST MIGHT not be done on Friday.... It isn't all about the decoder work, but some family matters has caused a few minor distractions. I am one of those persons that a 15minute distraction might as well be for 1/2 day, because I lose my train of thought and must have a tantrum or two also :-). There are NO setbacks, and all is VERY GOOD, both health and the decoder itself :-). So, just to forewarn -- I am trying to get things done so that there is weekend time to use the resulting version of the decoder, but just might encroach a little on the weekend before the release. John Link to comment
Popular Post rando Posted April 8, 2020 Popular Post Share Posted April 8, 2020 If it gives you a better window on the mentality of others right now. Let me assure you Wednesday and Sunday have very greatly reduced difference for many people right now. Especially where socializing and leaving home for entertainment are concerned. Work to your own calendar. John Dyson and lucretius 1 1 Link to comment
Popular Post John Dyson Posted April 12, 2020 Author Popular Post Share Posted April 12, 2020 I am still working on the release. A very very helpful early user has been helping me significantly -- doing careful review and measurement. He actually found a bug in an internal rate conversion filter -- I was chopping off the audio just below 20kHz instead of just above!!! At first, when he caught it, I tried to 'splain how the code was limited to 20.5kHz at 44.1k input rate, all about the filters this and filters that... THEN, when I actually measured it -- it was down about 2dB at 20kHz, and started rolling off at about 19.5kHz!!! OUCH!!! That was not intended at all. The root cause of the rolloff at 19.5 instead of the expected 20.5k? Stupid number/parameter in a filter. REALLY stupid mistake based on sloppiness. I corrected the filter, noticed that it was a little gratuitiously soft-knee'd, so I tightened up the filter and moved it out to about 20.4k -> 20.5kHz as it should have been. I really do take criticism seriously, and always try to explain to people what is going on. In this case, I explained how it SHOULD have been, and corrected the problem that I (both of us) found. It is SO nice to get good, technical criticism. Also, I added a finishing touch to another array of IIR type filters, whose phase slosh all over the place. Instead of a bank of those with a synchronized phase shift, I changed the scheme to have a cancelling phase shift, which makes certain behaviors much more precise and clean... The bandwidth problem (first one above) came from the internal rate conversion from 44.1k -> 66.15k -> 88k scheme, which also works for 48k -> 72k -> 96k. This is also applicable to DolbyA mode, if the auto rate conversion is used. (66.15k and 72k work INFINITELY better for internal processing than 44.1k/48k, so I do a very careful, mathematically safe conversion.) The phase shift issue is inside the feralA processing alone, and the imrpovement really does sharpen up the sound without creating an 'enhancement' effect. Still improving the decoder, but would be thought of as 'improvements' and not basic function. The basic functions are mostly solid and have been for a long time. The release will be coming soon!!! John lucretius and rando 2 Link to comment
Popular Post John Dyson Posted April 12, 2020 Author Popular Post Share Posted April 12, 2020 You'all probably know I am doing aggressive testing of the decoder right now. Have to make sure that I didn't break anything and sometimes even find bugs that i didn't notice before... This testing process will probably be another day or so, unless something else is figured out, or other bugs are found. Most bugs can be fixed in MINUTES, literally, but finding the bugs is the difficult part. There is a day or so of .wav file work also (actually an hour or so of work.) I am hoping that this next release this week will be a kind of 'final' release. There might always be minor improvements, but it seems like 'perfect' is getting better (well, you know what I mean -- the program is NOT perfect, but is working better than I ever thought that it would, considering the complexity.) I haven't intended to work on the basic 'engine', but only peripheral stuff. However, I keep finding improvements in the 'engine' part of the code. The .wav file stuff for usability stil needs to be added, but is so simple -- and these substantive changes to the hard part seem to get my attention because it has strong impact on the sound. That doesn't mean that the .wav stuff isn't important, but the audio quality stuff really scares me at times... THIS IS HARD STUFF TO DO CORRECTLY!!! Side note: I did get a wakeup call, oh so proud me... I have a specially/carefully selected set of ABBA albums on CD that I use for testing & demoing.... This is out of perhaps 50 ABBA CDs alone, I have selected 8 of them for each of their major albums. On another forum, someone mentioned that one of their 'Greatest Hits' CDs sounds really good -- naw... Nothing sounds better than my beloved collection that I use for testing, right?.... Bzzzt... Luckily, I do have that CD in my collection -- finding that it (and it's brothers, greatest hits and best singles type things) from POLAR music BLOWS AWAY my albums. The quality of the lousy 'greatest hits' is perfect, rather than just "okay". I sure wish my albums were all this good... I have been demoing slightly defective material and didn't know it!!! Geesh... (The "Greatest Hits" sounds better and measures better than my albums -- it IS better material for testing.) It really, truly pays to actually listen to other people!!!! John sandyk and lucretius 1 1 Link to comment
lucretius Posted April 13, 2020 Share Posted April 13, 2020 5 hours ago, John Dyson said: Side note: I did get a wakeup call, oh so proud me... I have a specially/carefully selected set of ABBA albums on CD that I use for testing & demoing.... This is out of perhaps 50 ABBA CDs alone, I have selected 8 of them for each of their major albums. On another forum, someone mentioned that one of their 'Greatest Hits' CDs sounds really good -- naw... Nothing sounds better than my beloved collection that I use for testing, right?.... Bzzzt... Luckily, I do have that CD in my collection -- finding that it (and it's brothers, greatest hits and best singles type things) from POLAR music BLOWS AWAY my albums. The quality of the lousy 'greatest hits' is perfect, rather than just "okay". I sure wish my albums were all this good... I have been demoing slightly defective material and didn't know it!!! Geesh... (The "Greatest Hits" sounds better and measures better than my albums -- it IS better material for testing.) Those two Polar CD's are the only ABBA I own (actually, I have one other not worth mentioning - a future thrift store donation). I'm really happy that you like these two CDs and I hope you will decode them and tell of your experience. ☺️ mQa is dead! Link to comment
Popular Post John Dyson Posted April 16, 2020 Author Popular Post Share Posted April 16, 2020 Status report -- there are further VERY substantive improvements -- there is a two-way method of EQ now, each one is similar, but different. Some recordings appear to use a single pole scheme, some appear to be optimal/easier to decode using the 2nd pole scheme. However, using the 2 pole scheme, when it is better -- it is A LOT better. The 2 pole scheme also further improves on the 250Hz intermod issue that somehow appears to be imparted in pop feralA recordings. Both schemes do correct for the intermod issue, but the 2nd pole scheme does its own needed tricks also. * the 250 Hz thing has been a real conundrum (or is it carborundum? ;-)) - I still cannot prove that it is correct, except for existence proof. It is almost like a lock&key, simple 'encryption' scheme of sorts... If the 250Hz problem isn't properly handled -- it creates a kind of buzz in the sibilance and other ugly problems. The FA decoder schemes remove the 250Hz IMD. ---------------------- So, current users know about --fa=1, and perhaps adding --fgh4 to add in the 4th filter (filter 1 is 4.5k single pole, and filter 4 is approx 12k single pole, dpending on the state of other filters in the chain.) (filter 0 approx 3kHz, filter 1 approx 4.5k, filter 2 approx 6k, filter 3 approx 9k, filter 4 approx 12k), but the 2nd order filters are a different shape all together. * The 2nd order scheme was actually my original scheme, but this is a vastly improved variant. The new command scheme still has the --fa=1 setting, but can addon the 4th (approx 12kHz) filter by just doing --fa=1,4 instead of adding the long (--fgh4) switch. About the 2nd order addon (really nice!!!): Next, there is an --fb, -fc, --fD scheme, where --fb is siimilar to --fa=4, --fc is similar to --fa=2. The cool thing is that when using maybe --fa=2 sounds okay, but maybe not really perfect, then maybe --fc might actually be better. Also, you can mix the 2nd order filters (--fb, --fc, --fD) with the first order filters '=1 or =2,4' or somesuch. I have NOT found a case where mixing the filters is needed -- but it is there if needed. --classical is still substantively the same -- but if I find a classical recording that doesn't fit the current/previous scheme, then it will be updated. I have privately mentioned that I have been fighting a lingering 'flu' (not likely COVID) for the last several weeks, really seems like a long time -- no biggie, except I am not productive like usual. When it is done (SOON) -- prob several days -- this new version has the potential for BLOWING AWAY the older version. John lucretius, rando, jabbr and 1 other 4 Link to comment
John Dyson Posted April 18, 2020 Author Share Posted April 18, 2020 This is an example of the 250Hz modulation that appears in the FeralA decoded material, but just doesn't seem right, and is not obvious in the raw/undecoded FeralA material. This 250Hz intermodulation component specifically seems to cause the MF band (80-3+kHz) expander to be upset, creating a 'buzz'. This is more or less prevalent on different recordings. The anti-250Hz can be turned off, but once one is used to the 'buzz' reduction, it becomes more and more desirable. (conceptually similar to 2nd harmonic distortion sounding okay, until hearing truly clean audio.) * I might be paranoid, but this problem is egregious enough that I wonder if this 'distortion' was added to the signal on purpose -- not very audible in the direct FeralA presentation, but mucks up an attempt to decode?!?!?!? THIS IS A PATTERN IN ALMOST ALL POP FERALA MATERIAL. It can be created very easily by a simple manipulation of the FeralA signal?!??!?! These examples show the subtle difference after removing the 250Hz IMD... Note that there *appears* to be a higher definition when the 250Hz IMD is left in the signal -- but the 'definition' is really coming from the 80-3kHz band being upset by transient excess 250Hz energy. The short Carpenters snippet is NOT the most clean recording out there -- but does show the buzz fairly noticeably. ALL decoding parameters are IDENTICAL, except for the buzz reduction in several places throughout the decoder. The 'clean250Hz' might seem a little more dull -- but imagine recording the vocal -- that high frequency buzz from the 'raw250Hz' version is NOT in a normal voice. That buzz is excited by the 250Hz IMD component. It is possible that the 'raw250Hz' version might originally sound brighter -- but again, imagine a real voice when listening. All such comparisons are subject to taste and preference -- but remember, my goal is to remove distortions that aren't originally in a recording (when I am not doing further damage.) With these changes, there are NO filters that have significant DIRECT audible effect above 1.2kHz -- most of the effect is in the below 1kHz range, yet the 'buzz' mostly appears to manifest in the 2kHz on up range.... There are two conceptual layers of 'buzz' or 250Hz IMD reduction, and 2/3 of the clean-up doesn't come from modification of the audio signal itself!!! Actually, there is little audible effect below 1kHz, yet is mostly a phasing difference providing the smaller part of the distortion reduction... The audible effect above 2kHz comes mostly from the correcting of gain control signal for the proper operation of the expander. That is -- most of the 'buzz' comes from the direct modulation of the 80Hz to 3kHz+ signal. (the 80Hz to 3kHz band actually goes up to about 6kHz or so because of very slow filter rolloff.) Interesting, huh? (Okay, I admit boring to most people -- but this is one of those nitty gritty details that aren't documented in any textbooks or even technical papers.) John clean250Hz.flac raw250Hz.flac Link to comment
Popular Post John Dyson Posted April 18, 2020 Author Popular Post Share Posted April 18, 2020 Referring back to my post about the really amazing Nirvana redo that I posted on the Youtube performances -- IT IS FERALA!!!! If interested, I can make a decoded copy available privately. Amazingly, FeralA decoding DOES work on mp3 and opus files, even works on the moderate quality opus as distributed on Youtube... BTW -- the difference isn't all that profound -- maybe cleaner lows, and the vocal is a bit less raspy, but that is it. The recording DOES test the DolbyA decoding component of the FeralA decoding -- the dynamics are actually significant, even causing significantly gain changes in the MF range (pop typically pins the MF band at max, or perhaps drops to maybe -3dB gain, but the Nirvana redo modulates all four DolbyA bands quite completely.) John jabbr and Confused 2 Link to comment
Confused Posted April 18, 2020 Share Posted April 18, 2020 A great clip John, and yes, I”d love a copy! Windows 11 PC, Roon, HQPlayer, Focus Fidelity convolutions, iFi Zen Stream, Paul Hynes SR4, Mutec REF10, Mutec MC3+USB, Devialet 1000Pro, KEF Blade. Plus Pro-Ject Signature 12 TT for playing my 'legacy' vinyl collection. Desktop system; RME ADI-2 DAC fs, Meze Empyrean headphones. Link to comment
John Dyson Posted April 18, 2020 Author Share Posted April 18, 2020 MAJOR warning about the new .flac direct play mode for Dropbox. I was elated until reviewing the online Nat King Cole decodes. OUCH!!!! Mp3 generally sounds better than my recent play of flac files. I don't know if this is a forever problem or not -- but ONLY use the .flac direct play feature in Dropbox for a quick listen -- NOT FOR ANY EVALUATION OF QUALITY!!! Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now