Jump to content
IGNORED

'FeralA' decoder -- free-to-use


Recommended Posts

Searched through the Supertramp archive, nothing there.   Lots of compressed & FA stuff, but nothing that is a pure recording.

 

On the other hand, an ABBA album in one of my alternate archives really appears to be pure.   It is a copy of 'VoulezVous', and my normal test copy, just a little 'missing bass' only needed '--p2l=1.5k,+1.5,0.577q' to sound almost, 90% the same.  (same cymbals, same intensity, no difference in 'mush').

 

This just might be one of the tests to determine which version is closest to accurate, or if any changes are needed to more precisely match.   The same archive has two or three other albums.  (I bunch the archives togther based on the genre of CD or other digital source.)   ABBA is by far my largest archive, mostly motivated by 'ABBA Gold' and the Supertrouper recordings that are so difficult to produce a clean result.

 

This is a relief, because there just might be at least one good reference.   Voulez Vous has a nice mix of highs and lows, some recordings with a modicum of intensity, etc.  This is a relief of some stress.  Since it looks like we have at least one reference, after I do an exhaustive search, it will sense to produce a decision.   If I have the energy, might even provide snippets of examples used for comparison.  (Because of my setup, it is much easier to play the decoder in realtime than to produce well controlled snippets, then also due diligence to make sure that I don't upload full recordings.)

 

 

 

 

 

Link to comment

Checked the rest of the repo with the good 'VoulezVous', and no others are useful.

 

However, I have been getting estimations on which version of the decoder are closest to the 'golden' Voulez Vous, and disappointingly so far, the comparison shows that V6.2.1W is the best.   The difference is just barely audible, perhaps inaudible, unlike FA.  V6.2.1X is really clean, the vocals 'pop' nicely, but the comparison is NOT favorable for accuracy.  If V6.2.1W wasn't so close to the reference copy, it would have been reasonable to say that V6.2.1X just might be a more clean version of the reference, but that really doesn't appear to be true.

 

A few minor changes of the decoder output were needed.  First, the LF on a lot of ABBA, after decoding, to get the right bass balance often need a +1.5dB LF at 1.5kHz.   However, the 'VoulezVous' decoding result also needed a 40Hz LF rolloff with -3dB, probably for maintaining record grove size, or might even be a decoder error where the bass is too strong.

 

There will still be more testing for a day or so, looking for more good references.   The best version so far, though seems to be the after V6.2.1V follow-on with minor cleanups which is V6.2.1W.

 

V6.2.1W will be on the repo within the hour.   The uploads of the demos are already in my private area, just need to do the transfer to the public demos and upload the correct version of the decoder.

 

Link to comment

More 'good' news, but in a critical way...

It does appear that the midrange (somewhere) has a slight error, MF not quite strong enough,subdB level, therefor causes very very slight 'beating' with the treble/descrambler.   Part of the midrange has some effect on the descrambler, and the descrambler is a very fragile thing.  Settings & EQ are critical, but it doesn't really sound like a descrambler problem by itself.

 

The problem isn't really noticeable without careful A/B, and I DO hear midrange and lower HF very well.   In fact, the error is more of a very minor artifact than anything else.  I tried disabling the anti-fog, and it made no difference in this area.

 

I WILL come up with a solution to this almost inaudible lower/middle MF 'difference'.   The HF is almost 100% identical, down to the comparison between the level of the sound of cymbals with the rest of the highs.   There is NO (absolutely NO) reason to do a release based on this information.   As soon as there is a plainly noticeable impairment, it will be placed in the work-queue and a release will appear in a few days.   The search for additional test materials (if existent) might take a day or more by itself.   After all of the information is accumulated, and addressed, there will be a new (truly complete) release -- and no matter what, even if no more problems, will be in the 'week' timeframe.

 

So, this is GOOD news in a mildly negative way....

It is possible to critically compare the two versions, ending up with a slight difference...

 

Apparently, still not totally convinced, but very confident, the decoder should be *practically* everything that I had planned it to be (after 5+yrs.)   This weekend might be a good time to 'play' with the decoder now.   BTW -- because of the mixing around the release times, I will also do a double-check that the versions are consistent.   That is, V6.2.1W is fully consistent and is exactly the same thing that I tested.   If a bug with the program crashing every occurs (or problems like that), the release to do an infrastructure fix would be identified as 'V6.2.1WA', 'V6.2.1WB', etc.

 

 

Link to comment

This usage note was in a private message just sent:

 

(THIS IS NOT ALWAYS/NORMALLY USED, probably like a 10% thing):

 

I do have a usage note...   When there are lots of highs, there appears to be a bit of a Nyquist issue, and some careful rolloff is helpful.   You *might* want to try:  '--p2h=24k,-3,be --p2h=24k,-3,sq2'. (numbers corrected below.)  This combo of rolloffs doesn't cause as much damage as it might seem by looking at the numbers (Q=1.414 does some special things when combined with Q=0.577).  The slightly gritty highs are in a way a bug, in a way not.   There *is* a '--hfrl=1', but it isn't well designed yet.   If you are 'squeamish' about a 24k EQ, then 30kHz is a proper alternative, but 24k is really good enough in most cases.   I doubt that 18k would ever be needed for this purpose.

 

ADD-ON:   correction to EQs above.   First try should be:

 

--p2h=24k,-0.375,be --p2h=24k,-0.375,sq2 --pvdh=24k,-0.375

Then, if not enough, try doubling the gain number from -0.375 to -1.5, on up to -3.0.   After -3.0, the problem isn't with the decoder rolloff, HF, etc.

 

The 24k (or 30k) EQ will not be included by default in the decoder.   It is against my 'philosophy' to 'tweak' the output unless absolutely necessary.

I'll make '--hfrl=1' be the same as '-0.375', then '--hfrl=2' is '-0.75', on up to the '--hfrl=4' is '-3.0'.

 

It should NOT take very much EQ to clean up the 'edge'.   Again, this edge doesn't happen on every recording...

 

This will all be documented likely in less than 1wk.

 

John

 

 

Link to comment

HONEST SECOND PASS APPRAISAL ABOUT V6.2.1W.

 

After a very fine comparison between the reference 'Voulez Vous' and the decoded version, the biggest difference wasn't actually the midrangb.  Apparently, there is a slight amount of mastering on the reference copy.   The dynamics are very so slightly 'smushed', but not compressed like a FA recording.   This harkens back to the old days when mastering was really done.   The reference copy is a little more smooth/flattened sounding, the vocals on the decoded version come forward more, while on the reference the vocals are slightly more buried.

 

However, the tonal balance is almost precisely the same, except a slightly different bass, and I have been trying to match it.   Basically, the output of the decoder needs a slight -3dB bass rolloff in the 70 to 150Hz range to very precisely match the reference.   Also, I have been hunting around in the midrange where the approx 1.5kHz rolloff (LF) is needed, and it is definitely -1.5dB, in the 1.75kHz to 2.25kHz range.   Both of these are exactly the EQ places that I have noticed on other ABBA recordings.  Between different ABBA versions, these locations (and also sometimes the 200Hz region) where the differences reside.

 

So, even without 'wishful thinking' the response balance difference is essentially nil, and the goal of 'response balance' is achieved.

I still have minor reservations about the dynamics matching, even though the reservations are slight and difference is only slight.   The reservations are ONLY because the proof is slightly more weak than response balance.    I am DEFINITELY going to review the dynamics and see if the current decoder design, with minor mods (shifting layers) can perfectly match, or is the reference recording REALLY slightly compressed?

 

SO, the only question is if the reference recording had a very slight 1.1 or 1.2:1 compression applied to make more listenable dynamics, or is there a misplaced layer in the decoder.   My own opinon is that the decoder sounds better, and has dynamics where expected, more natural vocal position (if perhaps there might be a minor layer offset in the decoder, NOT YET PROVEN.)

 

This is not meant to say:  there will be another release tomorrow, because THERE WILL NOT.   However, when there is cause for another release, the above issues will be further investigated.   So far, I am able to assume for myself that the decoder is working AS IT SHOULD.

 

 

 

Link to comment

Because V6.2.1W has been so good, I didn't expect to do another release.

There were two notable minor bugs found, the first not worth fixing immediately.   The second pushed the 'worthwhileness' scale up to 'extra release is worthwhile'.

 

The V7.0B decoder is available.   The current demos are very close to the V7.0B behavior.  With V7.0B improvements, I'll create new V7.0B  demos today or tomorrow.   The V6.2.1W demos should not dissuade because they are REALLY GOOD, esp when not doing direct comparisons with the original (still good though), or listening to very low level fadeups.   There is also an associated qualitative improvement with item 2, but that improvement is very nice, makes recordings sound even more clean, but not a forcing function to an early re-release.

 

1)  The layering on one of the layers had a 1dB error.   In the scheme of things, more minor than the 1dB might seem.  However, the result after the fix is slightly more smooth.  Totally inaudible without a very short direct A/B comparison with a reference.

 

2)  More important.  Some of the parameters based on feedback gain were still not calculated perfectly correctly.   The result of this error is imperfect tracking of the dynamics.  The error is most notable at very low levels.   On the other hand, at higher levels, the decoding result is now significantly more clean because the previously inadequate feedback errors made the result slightly 'soft' at high levels.  This item is difficult to discern unless directly comparing with a reference., but the correction does produce a nicer result.

 

Item 1 didn't worry me very much, but item 2 really does/did worry me.   Item 2 was motivated by a user/reviewer feedback.   Item 1 was self motivated.   Thank you 'anonymous reviewer' for your helpful information & feedback!!!

 

Link to comment

I am very tempted to publically announce V7.0B elsewhere also.

 

V6.2.1W has gotten nothing but good reviews (with minor caveats.)   V6.2.1W is not generally embarassing, but with the 'caveats', I know that other people will notice the already noticed flaws also.  The flaws are truly minor.

 

Since V7.0B has some aspects of 'studio sound', I think that it is unlikely to be embarassing.   It has the known V6.2.1W flaws addressed, mostly fixed.   On the other hand, V7.0B  is new, I have little experience with it,  and demos aren't available yet, I'll be holding back on 'global' announcement until approx +2days.  There *is* the possibility of a disqualifying attribute, but so far I don't hear anything that would disquality the release for announcing elsewhere.  So, there IS the possibility of deferring the announcement until after the next planned release 1wk from now.

 

Fun Fun Fun!!!

 

Link to comment

V7.0B public snippet demos and demos inputs for comparison are available.

A few of the private demo requests have been completed, but there are more to do.

 

This is the release that I plan to  talk about (softly announcing) (V7.0B) in other forums.  The mention will not happen if someone describes what is wrong.   I have NO schedule that the more public release needs to done immediately.   If it is best, I am happy to wait until the follow on/fix release abt 1wk from now.

 

https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

 

The sound quality improvements in V7.0B over V6.2.1W are mostly about a better presence, more accurate gain attack time, correction of the threshold of layer 5.   The DA decoder behavior must be very accurate, no slop at all allowed, but the previous versions had more 'tentative' & sloppy behavior by it's constituent DA decoders.  Versions earlier than the V7.0 series had both overshoot and inadequate gain -- this is not a happy combination, but the software can often work deceptively well.

 

I have done detailed comparisons between V6.2.1W and V7.0B, and the new result is 'clean' with strong presence, studio-like, but not over enhanced like V6.2.1X was.   Even though V6.2.1X really sounded enhanced, V6.2.1W also had an unplanned 'enhancement' where the control loops manifested overshoot.  This overshoot, bordering on ringing, made some amount of ugly 'enhancement' also.    I cannot  be relied on to judge the quality, so there will eventually be more trustworthy feedback that will help to decide whether or not to make public comments about the decoder elsewhere.

 

Every time that I worry about V7.0B being too bright, when comparing with V6.2.1W, some the 'W' version might have more  HF than 'V7.0B', yet the 'V7.0B' has a more clean sound.

  

Also, remember the HF edginess that was was worried about?   With the new, corrected feedback parameters, the edginess seems less of a problem without using signal rolloff.   Apparently, the edginess was manufactured by errors in the DA decoder control signal feedback loop.   On versions earlier than V7.0,  feedback loop created 'bounces & overshoot'.  The loop problems in V6.2.1W are moderately obvious on 'Telegraph Road' as described by the kind person who noticed it in the demos.  Those 'bounces' also caused some of the worrisome 'edginess'.   The time constants and gains for the feedback loop seem to have been done correctly this time.   I haven't recently heard the 'edginess' in the sound.  *The controlled, well designed HF rolloff is now implemented in FA decoder mode, '--hfrl=1' gives a nice amount of HF rolloff, but '--hfrl=2' might be needed in limited cases.   Up to '--hfrl=4' is available, but not needed.   The rolloff should not be needed, so let me know if you feel like V7.0B needs rolloff on a specific recording.

 

(The feedback loop(s) in the DA constituents of the FA decoder are not trivial, and are both nested and joined -- along with the attack/release rates of each composite element are dynamic, along with the control of the HF1 gain modification.)   Not simple stuff, and the details about the loops are not very intuitive.   The Sony patent design is more intuitive, but has 'design troubles' and also doesn't consider the timing complexities while emulating real DolbyA units.   The bug in the Sony patent is that it implies that you can simply change the z transform coefficents and not pay for it with glitches.   A state variable scheme would have to be used, yet the Sony design does not utilize a state variable filter scheme nor consider at all the attack/release and delays between HF0/HF1 because of nested gain control elements.   The method used in the FA decoder *only* way that I can visualize that the DA emulation can be done.   There IS one other way, and that would be a full electronic component emulation, but that would be very, very slow.

 

Hopefully, there will be no more 'emergency' fixes, and after all of my own reviews, it is unlikely that I will need to drive a 'quick fix'.  However, if a user/reviewer finds a problem, it might still force a new release.   It will be a high bar to force an emergency fix beyond V7.0B.

 

ENJOY.

 

Link to comment

WRT V7.0B --

I dare anyone to hear a substantive difference between decoded vs source except for cleanup, sometimes minor sibilance differences, sometimes uncompressed bass.

 

When I get my courage up, I expect to get beaten up at ASR,  I'll be 'chatting' there and a few other places.    I prefer kindness and tolerance, because I am quite a bit to tolerate :-).


My hearing is good now, and it was great to be able to finally do a precision comparison - my hearing that 'works' is the reason for my confidence today.

 

On the other hand, Yesterday, I did some 'decodes' of unmastered ABBA (beautiful), except I heard that it needed EQ.   Typical of my botched mastering, the results came out horrid.

 

Raw decodes of the unmastered ABBA now sound really good.   Guess I have a bad hobby for how well my hearing is working.!!!

 

Link to comment

ABBA decodes (bad news, public snippets.)

These were partially intended as test material as much as enjoyment, however these snippets DO NOT come from the normally available CDs.   Most claims about having an 'early' copy of ABBA aren't usually talking about this almost impossibly early genre of recordings.  I even forgot about this acquisition several years ago, being mostly engulfed in the decoder software itself.

 

The repo is under the subdir base name  'ABBA-wow', and below is a direct URL, but also resides on the normal public area.   All active versions are now updated to V7.0B decoder/demos.

 

There is one known 'questionable' behavior in the V7.0B decoder, and once my hearing is good enough, I'll work on it.  The problem is in certain intense HF situations.

 

ABBA stuff:

 

https://www.dropbox.com/sh/fyf9552jqno91c7/AABTYa9QE8JnroahE-WRmhHra?dl=0

 

For example, Voulez Vous actually sounds full, having rather high quality, and not all that intense, shrill like at least some CDs.   The Visitors has so much dynamic range that some tracks are too quiet at times, moreso than other versions.

 

Since the source material is very different from the normal CDs, the sound is also different.   The sound might seem more 'thin', but the 'thinness' comes from having less density, being less compressed.   It is difficult to describe the difference in sound, but when/if you listen to the demos, and compare with your own regular copy -- maybe I should upload snippets of a normal CD?, you'll hear the difference.   Which is better?  At least, from a HiFi standpoint, the version created from truly special sources is better.   From the 'comfort with the norm' mindset, then the sense of quality might be totally based on personal preference.

 

I *have* done exhuastive checks, also definitely factoring in my inability to compare freqs above about 7-8kHz.   There could be slight problems, but the comparisons were done during my best hearing time.   (I can easily hear up to/beyond 12kHz when all is good, just did the measurement.)   The previous, botched version with too much HF got positive reviews, but I do believe that the positive reviews came from kindness instead of being critical.   This new version is less severe, and should be perceived as very good, especially for those not accomodated to the normal ABBA sound.

 

John

 

 

 

Link to comment

Kind of bad news, but V7.0B needs at least one correction coming in approx 1 day (my habit of claiming a few hours mostly appears to be too optimisitic).

 

There are two known problems.   I have reproduced one problem so far.  The bug is so fundamental it needs to be corrected as reasonably quick as possible.   There also is another important reported problem that I am still trying to reproduce, and if it can be reproduced by me today,  that will be corrected oday also.  It is very minimally possible that the stereo image error could cause the other reported bug, but unlikely. 

 

The immediate, fundamental error is that the stereo image is 20% too wide.   Changing the stereo image is tricky because it is composed of two numbers, each one is individually important.    The correct width must result from multiplying the two numbers.   So, there are two variables, but the two variables are not mathematically independent, but individually important.   Without a specification, finding the two numbers is the result of exhaustive tests, and a bit of intuition.

 

(Stereo image errors can cause a lot of peripheral and subtle problems...   Surprised that I didn't detect it nor was noticed quickly.   Maybe the stereo image bug isn't easy to notice or detect? )

 

This is the first *fundamental* bug since the arguably correct release, and the several-days-lingering HF problem also needs to be resolved.

Along with addressing these two bugs, the next release will more correct support output EQ switches like:  '--hfrl' in '--skip' and '--equalizer' modes in addition to already working in  '--fa' mode.   Such EQ switches are never supposed to function in the base 'DA' mode though, and will not.  (DA mode is supposed to be 'pure'.)   Since my personal tests have essentially been successful, some work on the docs will start after this corrective release.   (Of course, my personal decoding results will need to be redone, but that is an automatic process that doesn't take up much of my time.)

 

I could believe that the release will come in a few hours, but since my estimates are often overly optimistic,  I'd suspect that the release will be more like 24Hrs than 'just a few'.      The project has been fully functioning from a very fundamental sense, but still has peripheral problems.   Being realistic, minor  peripheral bugs just might linger for another month or so.

 

John

 

 

Link to comment

The stereo image problem has been resolved in the test version, it is planned that the release will be V7.0C with the stereo image being the primary change.   There are also one or two other minor changes to support the optional Gibbs effect fighting command line options.   There is also one other very minor change to modify the drive to the descrambler (ends up being about 0.2dB at 30kHz.)

 

Initial evaluation shows that the V7.0C will produce a much more clean image, even better than the previous V7.0B.   This result is pretty good because the subjective image of V7.0B was already more clean and more distinct than the original FA.   Since the stereo image is more cohesive now in V7.0C, the result is quite impressive especially on some classical materials.

 

It is possible that the release might be V7.0D and be delayed for another day.   There was one other problem brought to my attention, but I have not been able to reproduce it yet.  I have guessed that the 'Gibbs correction' optional command might fix the problem.   This 'Gibbs correction' is invoked by '--hfrl'.  Earlier in development,  I had a difficult choice of enabling the correction all of the time, or make it optional.   Since the correction results from settings that are a kind of 'tweak', I backed off from the setting being enabled by default.   Tweaks must be avoided, or chaos will win.  Things are already complex enough and adding chaotic things just make it worse.

 

 

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

 

For those of you who might be interested in the quest to decode the most perfect copies of ABBA available, I think that I have finally found the answer to make the results sound like normal ABBA recordings, and not have the 'strange' sound that they have previously had.   The demos should be available in a day or so, but I have tried various approaches until starting from scratch again.   The new results come from 'starting from scratch'.   All settings have been carefully chosen, including the calibration offsets being used for precisely clean results.

 

The 'special quality' recordings are EQed differently, in fact very differently from the current style of recordings.   Apparently, there are two styles of EQ on the normal consumer versions...   One style as used on the 'ABBA' album, and another style as used on most of the others.   Both styles are very similar with a variance of one frequency in the chain.   Once this EQ is done, the sound is very similar to the normally available recordings, but with a worthwhile improvement in clarity.

 

 

Link to comment

Double edged-news.   The good news is that I found something minor/new that appears help the quality, the bad news is that it will delay the decoder for another 1/2 day or so.

 

Found an unfortunate' stupid programmer trick' of forgotten places where the round numbers like 3000.0Hz were used instead of the more correct 13.5*221Hz.   After the changes to the correct values, the resulting vanishingly small difference in actual numbers (in about 30 places in the code) produced a noticeably more clean result.   The only reason for the delay is that the sound is enough different that more verifications need to be done.   If I was more reckless, the version with the changes and perhaps, just maybe better sound would be released without the embarassment of this delay.

 

I'd rather give you the best, most clean result rather than meet some artificial time constraint, especially when the difference in delivery time might be 21:00 in the evening instead of the more quick 09:00 in the morning.   The V7.0D version is actually fully ready, already partially uploaded onto Dropbox, prepared to quickly move to the public distribution areas.   Instead, it would be better to fully prepare and test V7.0F, then carefully compare the V7.0D and V7.0F.   (V7.0E is an artifact of the version stuttering while V7.0D was near completion.  Therefore to avoid mistakes, it was best to skip the partially/development modified version to a more ordered version update.)   No matter what, either V7.0D will really be made fully available or V7.0F will be made available as a better version.   The best version will appear perhaps +18Hrs instead of +6Hrs.   At any time, if the new V7.0F is found to have new bugs, then we have V7.0D ready and the final steps to make it available will be completed.

 

The decoding results are becoming frighteningly good, and could possibly be deceptively good with a hidden problem.  Gotta test.

 

 

 

 

 

 

 

Link to comment

Version V7.0F, probably the ultimate of the REL9 series, is available. (further addressing the difficult-for-me-to-reproduce HF 'splat' is only potential expected update in REL9.)

All series of base demos also immediately available.

 

https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

 

A few little, but important improvements, possibly still one very credible known criticism, but this version just might fix the problem.   (Not enough HF rolloff causing distortions once in a while, in certain situations, certain systems.)   Just don't know how many situations are affected, but again there is an active attempt to fix the problem.

 

Super clean ABBA snippets are almost ready, sometime tonight or tomorrow.   There is a very plausible version right now, but definitely needs further careful review.   A more formalized, very useful method for decoding massive numbers recordings will be documented.  The ABBA decodes were used as a prototype for one practical version.   Since the ABBA decoding operation had unknown post decoding EQ requirements, the separation of 'decoding' and 'EQ' is more completely tested.   The methodology is being captured and will be added to the docs.

 

Part of this methodology for separating decoding and post decoding EQ will encourage sharing the decoding parameters for certain series of albums.   Few recordings really need the 'parameters' at all, but those recordings that benefit, do benefit greatly.

 

 

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

 

The improvements include:

 

Added approx 0.6dB rolloff at 26kHz, a primary brickwall filter freq. (Brickwall needed because of the effects of dynamics processing.)

 

A corrected mistake that used the wrong series of constants.   The corrected numbers improve the sound/clarity/timing of the highest freqs.

 

Expanded support for '--hfrl' and '--finish', both in functionality and so that they are available both in 'decoding' mode and on 'equalizer' and 'skip' modes.

 

Hopefully final adjustment for the threshold calibration value.

 

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

 

Coming 'improvements':

Usage doc, usage doc and usage doc.

Full manual...

 

If the decoder IS stabilized based on the goals of REL9, then there will be a chance that the docs will start being available in approx +1wk or so.

 

 

Link to comment

Good , bad and neutral news...

 

Neutral news first:

I have started describing the actions of the decoder as 'anti-blur'.   This is because the FA encoding is apparently a 'blur' and detail obscuring scheme.  Given the 'blurring' process, recordings cannot go through the distribution process more than once without obvious damage.  (Only justification that I can find.)   It appears to reside on the distribution masters for older recordings, perhaps the reason why some of the MFSL stuff appears to be based on the 'FA' version instead of the final studio copy.  Some day, we'll find out what is really going on, but in the meantime, the decoder really does work now.   It does make me wonder if the original copies before FA weren't destroyed in one of those 'fires' a decade or so ago.   If so, the decoder might be the only way to retrieve the recordings.   This makes the quality of the decoder results absolutely paramount.

 

Good news:

There is a new LF EQ that will make the low lows more realistic and also mostly correct the <200Hz dynamics.   I didn't know about the dynamics issue until today, and the side effect is apparently that the lows are more 'flat' sounding.

 

Bad news:

There will be a release soon to correct the LF as described above, and it might not be until the weekend starts.   However, I'll try to be able to upload it before +14Hrs (2100 USA EST.)

 

Other info:

I had a 'panic' about the potential need to add another decoding layer.   The potential layering bug  was the reason for the 'false alarm'.   This panic resulted from the difference between the 'decoded CD' and ripped 'direct to disk' for Sheffield Labs 'I've got the music in me'.   After further review & analysis, I realized that the tape copy used to make the CD was most likely a safety master tape.  Given that, it was also likely that there was a modicum of compression done to avoid exceeding whatever highest tape signal level that would be tolerated.  Since the difference was at the strongest level of 'Thelma Houston's' voice, it was likely compressed.   When carefully reviewing the CD and decoded versions, the voice was definitely dynamic range compressed at the highest levels.   So, the difference was nothing to do with defective decoding.   The panic morphed into relief and the online messages were changed into 'nothing important'.

 

Except for the compression at the strongest levels of Thelma's voice, the 'Ive got the music in me' is a good existence proof for FA encoding.

John

 

 

Link to comment

Subtle, but some amount of proof that the descrambler works.   These are snippets from Carry on Wayward Son, Kansas.

RAW is direct from digital distribution, DEC is after decoder processing.   The dropbox online player totally obscures the difference, gotta download or use tool other than dropbox player!!!

 

ADD-ON:  forgot to mention, ONLY the descrambler is processing this.  The dynamics processor (DA constituents) are essentially maxed out, all running at full gain.

 

https://www.dropbox.com/sh/4e3rw9j8cxqtkri/AAB9hJlQ5B_GJpOSBlS0ujmSa?dl=0

 

IMO, the big difference is that the peaks are less buried after decoding.   This requires careful listening when 'disembodied' from the recording, but is noticeable when sensitive to such things.   It might be reasonable to claim that the 'RAW' version has 'blur' added during the FA encoding process.   Subjectively, it is up to the listener, but I can blind A/B it, so there must be some increase in intensity in the peaks (less buried intense details.)   So, the effect of the 'scrambling' during the FA encoding process might be considered as part of the forced generation loss/blur.

 

Thankfully, the decoder EQ has been improved over the recent releases, the relative spectral response (ie.  apparent frequency response) is flatter and flatter, subjectively so far V7.0G is flat to me.

Before V7.0G, I could still say, 'something worries me' about the sound.   So far, while testing 'G', I cannot detect anything seriously undesired so far.  There are SOME minor response bumps in the LF spectrum, but the measurement technique has bigger errors than the bumps themselves.  (The bumps are effectively vanishingly small.)

'G' fully exists, demos are running, and will be building the Windows version in just a short while.

 

It will likely be >2Hrs before the demos are ready, as an experiment, the '--xpppp=max' decoding mode is being used.   This is the highest available and practical quality mode in the entire decoder scheme.   Just for laughs, but it is very very slow.

 

ENJOY!!!!

 

 

 

Link to comment

Frustratingly, V7.0G is a bust.

There was always a problem where I felt, but couldn't measure or prove, that there was a bit of an upward tilt in the HF.  Didn't hear a lot of tilt, but I am incredibly worried, bordering on paranoid about HF tilt.

 

Found the reason for the tilt ONLY after everything was ready for V7.0G to be finished/finally  uploaded, etc.   I almost always do a final check through the code, but I sure wish I found the problem/mistake 6Hrs ago!!!

 

What was the problem?   Stupid programmers trick...   Initialize a variable at rolloff=-0.75dB, for example, expecting a rolloff.   Instead, I used '-rollof' in the subroutine calll, thereby giving a boost.   The amount of boost wasn't all that bad because it wasn't in a sensitive place, but the setting is simply incorrect.

 

The release will still be coming tonight because my goal is to make the decoder available for availability the entire weekend.   The only 'hit' other than a 4-6hr delay is that the decoding operation will not be done at '--xpppp=max', but only '--xppp=max' to limit the amount of delay.   '--xppp=max' is certainly "good enough" quality for sure.

 

Darn-it, why can't I do something without making mistakes?

Well, at least, V7.0H will be better in some technical ways than V7.0G.  The tilt wasn't all that big a deal, starting at 27kHz, so seing perhaps +0.25dB at 20kHz.  It was simply wrong.

 

John

 

Link to comment

V7.0H is ready now.   Sorry about the 7Hr delay, but moved as quick as possible.

The sound is more tight because of the more correct bass/highs interaction.   The interaction is a delicate dance, now very tight.

 

https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

 

Hoping that this release starts focus at on the immediate start of the Usage guide, also restart on my decoding projects.  Frustratingly, this new release forces restarting all of my decoding projects.   I don't lke decoder releases either, but sometimes updates must be done for project intergrity.   Updates will be less and less often, and should further slow down after this release.   Hoping no sound quality changes in near future, but that hope appears to futile.  I know of absolutely no quality problems anymore.   Even the most subtle HF sound appears to be correct.

 

Fixes since last release:

 

More flat bass.   Sound match is better.

Corrected (simplified) interlayer bass EQ, improves the bass/highs interaction so there is less 'bass/highs' wobble in the sound.

Corrected the built-in audible HF rolloff, needed to avoid the possibility of Gibbs 0.8dB overshoot.  (disabled by the '--raw' switch)

 

Other important correction since earlier version:

Use more correct constant values for the nominal 3k through 30kHz EQ freqs.  (note, the frequencies are not on 'even' bounds, but must be multiples of 221.5Hz.)

Slight modification of the HF 30kHz rolloff compensation intended to better emulate DolbyA HW.

 

 

Link to comment

For the few of you actually using or doing comparisons with the decoder, are the middle highs too strong?   My hearing is clear for the first time in a few weeks, and there is an opportunity in the response curves for a slightly exaggerated 4-8kHz in the decoder output.   It can easily be changed, but I couldn't hear it until just now.

 

I'll produce a prospective version without the potentially exaggerated 4-8kHz and ask that the decodes be checked.   It sounds good (to me) on some recordings, but makes things sound metallic.   Again, bordering on trivial to fix, if it is really there.

 

ADD-ON:   Thank goodness that I could hear well today.   The correction is to MOVE and EQ, not actually change the value.   The 'game' in the decoder is about being flexible, and more often than not, when the settings are close to correct, fixing it is about MOVING, not actually gain settings.

 

Still gonna get feedback, but preping for the change.

 

 

 

Link to comment
2 hours ago, John Dyson said:

For the few of you actually using or doing comparisons with the decoder, are the middle highs too strong?  

 

 

 

Yes, a little.

Imo the 'F-version' generally has a better tonal balance in the mids than the 'H-version'.

Link to comment
11 minutes ago, dkskl said:

Yes, a little.

Imo the 'F-version' generally has a better tonal balance in the mids than the 'H-version'.

Thanks, I greatly appreciate and respect this help!!!

 

SO far, it appears that the descrambler was processing 6kHz band (6k to 9k) too aggressively.   There are 0.5dB steps that the descrambler can be controlled, and the max is 1.5dB.   So, the next tests are running with 1.0dB instead.  (I know, the numbers are meaningless out of context, but just giving an idea about what is going on.)   With the descrambler turned down, then those ugly upper-middle highs are less intense, yet all of the detail will still remain.

 

Currently, the 2nd version of J is being tried, and might even require a 3rd try.  It isn't 'tweaking' except by the descrambler change described above or moving some EQ by moderate changes in frequency (say, 221.5Hz in the range of 3kHz.)   There is also a built-in rolloff intended to mitigate the Gibbs effects needed in the decoder design.  The rolloff also must be carefully considered, because too much rollof can actually sound REALLY bad and make sibilance sound 'stunted', almost 'suppressed.'

 

My guess is that the 'J" release will be coming in a few more hours.  These tries are not as simple as a change and 'quick check', but require comparing perhaps 10 or so recordings, and even then it is tricky to make things correct, esp with bad hearing.    I am a little disappointed because I was really hoping that the quality problems had all been resolved.

 

THANKS AGAIN FOR THE FEEDBACK!!!

 

John

 

Link to comment

 

 

Amazingly, during this 4th (YES, 4th) try for the V7.0J release, I am hearing details in 'Why Worry' from Dire Staits that I have NEVER heard before.  There is a strong 3d effect in the sound   And like usual, hopefully the frequency balance is correct.   I know for a fact that the HF response is less intense, because it can be measured and compared with the previous version, and also the descrambler is running at a less aggressive setting.

 

Many tries get stopped, and then restarted because the recordings are reviewed as they are completed. 

 

There is a REALLY cool demo that shows the improvement especially on classical recordings...  This example (Blue Danube) was randomly chosen and found.   This result comes from exactly what is intended to be released (well, as of now.)  Any released version will have an even better stereo image than this example...

 

Look for the Beautiful Blue Danube examples at the link below, as usual RAW is from the CD, DEC is after being passed through the decoder... 

Make sure that you are in a position that it is easy to 'visualize' the stereo image...   The improvement is profound.

https://www.dropbox.com/sh/wuftdgtwnke5lsx/AAAvw-3PZrz1aqQhoM0DZKjaa?dl=0

Link to comment

V7.0J decoder is uploaded/ready, the normal snippet demos are uploaded/ready, everything else is uploading right now.

Because of a confluence of fortunate events, the 6kHz should be much better, better chance of being truly correct.

Certainly sounds better anyway, MUCH BETTER DEPTH IN STEREO IMAGE.

 

ADD-ON:  after all of the blather, I think that 6kHz is still too hot.

 

https://www.dropbox.com/sh/i6jccfopoi93s05/AAAZYvdR5co3-d1OM7v0BxWja?dl=0

Also, uploaded the source.  If you get it, try to read it, please don't make fun of me -- it has been 'worked on' for many years, and is very substantially, incredibly intricate and complex.

 

 

Explanation/blather...

 

The strength of the 6kHz descrambler was decreased to better control the 'metallic' and 'intense' sound in the 6kHz region.  Some strange, very seldom  'jerking' effect is also corrected.  It is pretty obvious that the 6kHz band of the descrambler was previously not in sync with the other bands.   Other descrambler bands were checked for strength and enable state.  only the 6kHz descrambler band needed to be changed.   All other enabled bands 9kHz, 12kHz, 18kHz, 24kHz and 30kHz still are all fully enabled.  3kHz and 4.5kHz didn't need to be enabled.  The 6kHz band is now  2/3 enabled, and that appears to produce most correct behavior.

 

Since the 6kHz band changed, other interacting HF EQ needed to be revisited.   Also, , it still seemed like there was still too much HF by a slight amount.  The HF EQ was totally reevaluated (same structure, same gains, different freqs) and resulted in a change of about -0.2dB at 3kHz, -0.6dB at 6kHz relative to the previous version.  The actual 6kHz descrambler response varies and so the '-0.6dB' is only a nominal measure.  The additional HF change was to move an EQ by 221.5Hz residing in the 2-3kHz range. 

 

After the changes, the specially measured gain shows reasonably plausible 'flatness'.   Raw measurements do show a decrease above about 7-8kHz, but is expected because of the HF expansion behavior.     Of course, the descrambler confuses the measurements, so the raw measurements are approximate.   It IS good news that  the entire range of about 200 through about 6kHz,  is measured (inaccurately) to be approx +-0.15dB.   The measurement below 200Hz shows a bump causing +-0.30dB.   Above 6kHz, there is a 'droop', but is caused by the levels being lower, and expansion decreasing the gain.   If the response measured flat above 6kHz given the current signal source, the response at 20kHz would actually be about +3dB or +4dB too strong.   The 'droop' represents a flat response.   All of the measurements, esp at the ends of the spectrum are NOT accurate, and at the ends of the spectrum might just be totally erroneous.   Unfortunately, these are the only objective and useful response measurements available.

 

Also, along with all of the HF changes, a careful review of 'tilt' was needed, along with the HF pre/de-emphasis curve.   I believe that the tilt was re-flattened, with the resulting 'pop' of 3d stereo image.   The 'depth' part of stereo image has always been troublesome, even though  the width has recently been okay.   (ilt is incredibly critical, where a 0.1dB tilt from 6k to 20k  can make a huge audible difference.   Recent versions have always had a too-strong upward tilt.   With other HF eq being substantially improved, the HF tilt was also addressed, now with a slight downward direction.   Most of the time, the sound will be more clean, seem more detailed. Unfortunately, the slight downward tilt does cause some 'choking' in certain instances of sibilance.   The 'choking' doesn't happen very often at all, but some day I'll revisit the issue with a further modified output EQ.   The tilt correction EQ can be fully disabled by using the '--raw' switch.   The sound with the '-raw' switch is less clean sounding, the switch being intended for those doing all of the EQ themselves.

 

This version, V7.0J is producing a very reasonably good 3d (depth and width) stereo image.   The 'depth' is probably better than any previous version.

 

 

Link to comment

I deeply apologize for the 'panic attack'.

V7.0J is probably okay.  It is probably my hearing causing confusion again.

 

We need to wait for feedback, but V7.0J really is sounding reasonably good.

There might be some emphasis of the 6kHz region, and there are some things that we can do, but really need to know.

 

If V7.0J is good, it is wonderful for sure.

 

 

Link to comment

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...