Jump to content
IGNORED

MQA is Vaporware


Recommended Posts

17 hours ago, Lee Scoggins said:

 

I wasn't going after Pro-Tools so much as the engineers who just record in 24/44 or 24/48.  Joe Palmaccio in Nashville and many others have been railing about this for over 10 years.  As someone who likes the best possible sound, I have been discussing this on the Hoffman board for a similarly long period of time.  My view is that 24/96 or better is ideal.

For processing --  for the best quality you really need more than 48k for the general case (where you don't know what kind of processing is being done.)  96k (or 88.2k) is the next higher sample rate that makes sense.  48k/44.1k sample rates are okay for delivery or simple applications, but lock you in to some problematical issues.  (Of course, you -- or the processing product -- can do up/down conversion, but that isn't really a good thing to do if can be avoided.)

 

Nowadays, with HW being so common, and plenty of disk space available, I don't see any reason at all for production not to use anything at 88.2k/96k or above @ 24 bits no-lossy compression involved.  Actually, 32bit floating point is better -- opens up some dynamic range mistake recovery during processing.  192k is nice, but mostly overkill for audio (real audible audio) applications, but other than overhead, really cannot hurt.  Also, the integral up/down conversion to 192k isn't too awful -- just best to avoid. There are a few minor additional degrees of freedom when using 192k sample rate (I am speaking of the DSP issues), but I would hope that most competent developers can avoid problems with processing at 96k.  48k is less easy/more trash can be left in the audio.  44.1k is simply ludicrious to try to do certain kinds of processing directly.  Also, there is a VERY VERY slight spectre of some Gibbs effect when up/down converting to/from 44.1k -- but NOT for linear applications.  Things like limiters/compressors have to do their duty carefully to avoid the sidebands wrapping around Nyquist rate.

 

The big problem with 48k (or 44.1k) is NOT problems for listening purposes, but one problem is there are some kinds of processing that produce sidebands in the audio -- those sidebands can easily (very very easily) create aliasing.  Linear processing -- no problems -- even doing up/down conversion (other than the well known issues.)  For nonlinear operatoins (like limiters/compressors/clippers/etc), best to avoid the lower sample rates.

 

Link to comment
3 hours ago, The Computer Audiophile said:

The limitation is usually the total bandwidth required. 96 or 192 is great unless one needs a ton of tracks/channels. 

Maybe, in that case upconverison/downconversion might be appropriate.  However, at 192ksamples/sec * 4bytes/sample*16channels is 13Mbytes/sec.  If/when you REALLY need 16 or 24 channels and not just playing around, that isn't all that much.  A computer HDD is capable of 100Mbytes/second, and whenever processing those channels in HW, one would USUALLY do it in parallel, so the bandwidth per channel isn't all that big a deal.

I can acknowledge that 192k is probably excessive, especially for pop music,  so 96k might be a reasonable tradeoff.

 

My software is incredibly 'dense' with signal processing (it is difficult to describe the amount of processing -- but it is written absolutely the most efficiently as possible, and takes 3 cores of a Haswell CPU -- 3.3/3.4MHz because of the SIMD instructions throttling the CPU -- to run realtime.)   Very LITTLE procesisng in audio (unless maybe something neural net based) would need ANYWHERE near as much CPU.

 

For example:

(My software for resources for 2 channels each:  does over 200, different 300-1024 tap FIR filters, 64 different 1024 tap (super accurate) Hilbert transforms using DP math  & BLACKMAN 92 windows to maximize accuracy), and that only takes 3 Haswell cores realtime.   I doubt that many situations require this much processing in REALTIME @ 96k samples/sec for the entire chain!!!  Additionally, the timing is tracked perfectly, so that the input/output files or realtime output is accurate sample per sample!!!

(BTW, the code runs well over 98% of the time in SIMD instructions -- LOTS of math.)

 

So, it seems to me that generally working with 16channels at 96k/floating point samples is not beyond the capability of a workstation.  (Running my software 16 channels in realtime on a normal workstation might not be practical , however running at 48k and less quality only doubles the speed) Additionally, more than 4 cores is regularly available nowadays.  I am, of course, assuming  moderately efficiently written code.

I'd suspect that very few channels for very many applications need nearly as much processing as my software in most cases.

 

John

Link to comment
9 hours ago, mansr said:

With headphones and the volume turned up, dither at 16 bits is audible. Since it's easily possible to lower the noise level, there's no good reason not to.

I wish that small amounts of noise were audible to me -- 62yr old tinnitus...  Frustrating...  (However, I believe in the criteria being normally audible, and I listen to music that was originally on analog audio tape...  FOr that, the hiss on the tape makes pretty good dither :-)).

 

John

Link to comment
28 minutes ago, Lee Scoggins said:

 

I'm okay with members having different opinions on formats but the argument was not about 16/96.  There are few files encoded in that anyway and maybe zero commercial releases.  The argument was about 24/48 versus 24/96.  24/96 is clearly better.  The higher sampling rates do matter.

 

Your tinnitus may be impacting the frequency range but recent research suggests we hear timing distortions down to 5 microseconds well into our 70s.  Maybe you are doing okay on hearing the timing elements.

Well -- I must have mistyped -- because I was thinking 96k/16 when I typed 96k/24...  However, that is my mistake and confusion (I have been under blinding and overwhelming pressure...)  Can we forgive my mistake ? :-).

 

John

 

Link to comment
  • 2 weeks later...
25 minutes ago, Jud said:

 

I think @The Computer Audiophile hit this exactly right in his presentation.  In a world where we think nothing of streaming video on and through our mobile phones, where you can pick up 4-6 TB of storage for less than $150 at a local store or online, and where both these situations are going in the direction of faster and larger, cheaper - MQA is a solution whose time has come and gone.

 

Pay attention to the presentation video: Chris's slide about 5G and mobile/wi-fi speeds getting faster was something that really set off the MQA folks.  Now whether you know anything about the technical side of MQA or not, you surely see mobile/wi-fi/home internet speeds getting faster, and you surely know that streaming video, let alone streaming audio, is ubiquitous on the Web, home or mobile.  And you therefore can understand that there is no consumer value to MQA's file size minimization, whether via compression or the ADPCM (adaptive differential pulse code modulation) @Paul R mentioned.  But right there on the video you see MQA arguing against the faster cheaper future everyone knows is coming (really, for streaming audio purposes, is already here), because they realize it means at least half their supposed value proposition is quite evidently worthless.

Okay -- I do agree that data compression of audio is of less importance than today.  However, there are still cases where compression might be useful.  Maybe a LOT of compression of good quality might be more useful than some compression at the highest quality.  Where bandwidth reduction is needed -- then a lot of reduction is needed.  Data reduction for storage reasons is of less importance (or the need is less common.)

When I need data storage size reduction, I am happy with flac -- it does just enough to be worthwhile, and except for material that has data out of range, is good enough to store the data that I normally use floating point for manipulating.  Usually, flac is otherwise good enough.

I have to admit, sometimes I do play with flac's apodization options to maximize compression -- but the benefit is similar to that of twiddling thumbs.

 

MQA is optimally unoptimum in yet another way -- time has come and gone -- after digesting the informaion/thinking about it --  I do agree.

 

John

Link to comment
5 minutes ago, botrytis said:

 

None taken. I was just trying to point out  the similar style in thought process, not they are in the same vein of severity at all.  BUT, it is a common denominator to this type of thinking.

Thank you so much for not taking offense -- I HAD to let off some emotional steam.  I truly give a darned and cannot fix the problem for everyone.  It would be nice if the snake oil perveyors could get an honest job also!!!

I love my music (however tired I am listening to it right now -- doing it for a project), and I wanna make it more available in the simplest, purest form possible.  I want no more strings attached, everyone abiding by the licensing (within reason), and want everyone be able to enjoy their hobby, profession, or simple casual listening.  It really doesn't need to be complicated...  Some people try to make it complicated  anyway.

 

John

Link to comment
9 minutes ago, sandyk said:

 

 John was talking about properly decoding Dolby encoded originals.

In this case, having checked out his linked to before and after versions, I would definitely agree with him.

Thank you -- with some serious work, and some help from a significant audio professional -- the decoder quality is lightyears better yet.

 

The main reason why I use ABBA (other than as ear-candy) is that the mixed female vocals with a wall of sound really drives a fast gain control system totally bonkers.  It is wonderful (and tough) test material.  Easy stuff, like Carpenters, doesn't really test the software.  Carly Simon's recordings are kind of tough also.

 

A lot of undecoded material is available.  The Carpenters' album from HDtracks is apparently undecoded, for example.

 

I am NOT claiming that everything is encoded for sure, and the decoder sounds BAD (grainy, sometimes REALLY bad) on unencoded material.  The decoder (DHNRDS) will destroy the sound of unencoded material, but leaked DolbyA material (sometimes with a small amount of EQ) will produce a master quality result.   Apparently, some distributors have apparently believed that a shelf of -3,-5,-6dB at 3kHz/Q=0.707 is 'decoding' DolbyA material.  Not really, but that is what has happened to some old material that sounded kind of 'harsh' or didn' t have any 'depth.'  It  is sad indeed.

 

 

John

Link to comment
4 minutes ago, sandyk said:

 

 It would be interesting to hear some segments of the corrected versions vs. the non corrected versions if you get around to doing this.

 Can you name a specific Carly Simon recording that was undecoded ?

DO you want me to show some material?  I don't have a site anymore to demo -- but I can email a copy of a snippet or two if you want. (I am infinitely trustworthy.)  If you are serious -- I can provide a temporary email address so that we can get started...  (I also ahve dropbox, but it seems more complicated to use.)

 

This was an online purchase from somewhere a few years ago.  A lot of digital material hasn't been decoded (definitley not all.)  A lot of my originals are in storage, but I have an encoded Queen CD from Hollywood records (I think) immediately available also.  The Carpenters example was downloaded from HDtracks.

 

John

Link to comment

Okay -- anyone who wants to email me, and request some snippets (before and after) on the DolbyA compatible decoder (not supposed to say that) -- I can do so...  I am not sure about this temporary email thing -- so I hope I have done it correctly:

 

[email protected],

 

then I'll send you a short 'Carly Simon', 'Brasil'66', 'Carpenters', or  'ABBA' example.  Just tell me -- Carpenters isn't so good (but had been popular).  I think that I have Petula Clark also.  There are a few that I am NOT sure if they are encoded (sometimes hard to tell -- most of the time they sound like H*ll if not), but I do have more.  I'll keep it to something reasonable (maybe 60seconds), and really should send flac for the best quality.  (The decoder does certain things so well that mp3 can be embarassed.)  Sometimes, the decoder *does* choke, however.

 

John

Link to comment
Just now, sandyk said:

 Hi John

 It's probably better to just name particular albums  for the members to check out themselves from their own collections if possible, than risk copyright infringement.

I would however be interested in hearing what you have done with the Carly Simon album sample.

Kind Regards

Alex

The problem is that a lot of my CDs are in storage.  As long as the cut is short, shouldn't be a problem (not talking about sending the enitre recording, but a chunk of it.)  I wouldn't transfer more than 1 minute in any case (yea, I know that 30seconds is usual and would cut it that short if it was enough to demo.)  I seem to remember that many of the ABBA Gold from the early 1990s are not decoded (ABBA Gold & More ABBA Gold.)  I have a Hollywood records copy of Queen from about 2004 (it is encoded.) 

 

Looking around for material that I still have metadata online (it just gets in the way.)  I'll look in the headers to see if I can find the album information for some examples.

 

I am trying to figure out a way to explain how to determine if something is DolbyA encoded (I can distinguish because of experience) -- for example, the sound has poor spatial image, and also the highs have a suspicious kind of compression -- it is faster than usual.  Often the hiss is stronger than it should be (look at a spectogram on Audacity, for example.)  I think that the strongest indication tends to be the very flat spatial image and the high hiss level on the recording.  The compression is sometimes difficult to disinguish because it is so very fast (I can describe the arrangement, but at freq above 3k, the release time is about 30msec 1pole for fast transients and for dwell times greater than about 10msec is something like 40msecs+30msec release time (2 poles).)  That is a very fast release time.  The saving grace is that the gain changes are mostly between -20dB and -40dB.  The DolbyA is roughly flat above about -10 to -20dB, but the compression at the lower levels really does significantly  boost the highs.

 

Unfortunately, I cannot send the decoder itself -- it is a matter of project integrity, we have been thinking about making a consumer version, but that is planned to NOT be the market for now.  So, this makes it difficult.  Once we start selling -- I hope to lobby for a consumer demo version that runs only at 44.1k/48k and only runs at the lower quality settings.   Low quality on the DHNRDS is generally better than DolbyA HW...  So -- it would be useful for the consumer app.  Once we get our acts together -- hopefully something might be able to happen in that market.  (I own the software, but the project is shared with two, and possibly a third person who wants Telcom C4.)  The project integrity must be maintained...

 

I'd like for the consumers to rattle the cages of the distributors, and at least get the old DolbyA units out to decode the material!!!  The 'real deal' sounds a LOT better than the mushed up compressed shrill sound (at least, they EQ it!!!)

 

John

 

 

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