advertisement


MQA pt II

It would be good if someone can see if they can replicate this to pick up any error I've made. Details...

The gross time offset between the 88k full-content files is about 1.667 sec. That should get you to within a couple of dozen samples (88k rate) of alignment. (It looks like 18 in what I got.) I grabbed sections with that initial time offset which last about 15 sec, targetted on including the noise burst. The xc was over about 11 sec span of samples/file.

The process noise seems 'randomised' enough to be dispatched by the xc process over that span. At least, sufficient to show the filter pattern remains dispersive and familiar. Looks like the waiter adds the same ketchup, though.

The peaks are lower because the process noise alters the normalisation. It is part of the unfolded signal power which is rejected by the xc, so you only get the fraction in the 'common' pattern in both input and output.

BTW The plot shows both channels... well it would if one didn't neatly overlay the other!. So in a sense it is two scans.

I'll now get back to what I was supposed to be doing today. But couldn't resist trying the above, and said "Bingo!" when the result popped up. So worth a try. :)
 
I can't see what your origin for this is, for the 'bound'.

MQA decimation (192k to 96k) is bound to be minimum phase and leaky because that is what they believe in, but this does not pertain to an 88.2k or 96k original.
"because that's what they believe in" is all I meant really. They are going to have to use some sort of filter. As for the 88/96Khz file, I guess it's the same, except they don't have to use a decimation filter. But if they think that the all pass filter deblurs a 44/48 kHz file then they probably think that about 88/96kHz files too. After all the blurring matters irrespective of whether it's at audible frequencies because, you know- "time domain".
Actually I don't think the encoder was overloaded to the point of breaking: if was driven hard, much harder than music would do, and thus its response is untypical in that there is now simply too much of the shaped noise MQA employ to hide the jewels in.
Interesting. So MQA's critique of the relevance of GO's files perhaps a little overstated?
 
I've now added the 88k filter results to the webpage at
http://www.audiomisc.co.uk/MQA/GoldenOne/ChallengeAndResponse.html
so people more generally can see the results.

In essence, what seems to happen to the 'standard band' audio is just that some process noise gets added, mainly up at the HF end. (The bulk of the process noise is higher.) But you get the dispersion 'ketchup' added. I'd welcome someone who can communicate with GO finding out if anyone asked him what ADC he used, or if he wanted this to become his 'Master'. Otherwise it seems like making a blanket change to get a result that *differs* from the 'Master' to me. Does the waiter ask chef if he can add ketchup on the way to the table?
 
OT

But yes, 44.1k MQA might mess with Dolby tracking. The OP in that TH thread has not specified the DAC used. Maybe it is NOS, which would be even worse than MQA in this respect. With recording you have to ensure that nothing above 20kHz hits the Dolby encoder.
 
OK, I've done the bulk of all the 'other things' I wanted to deal with. Just have one that should be finished tomorrow. Then I can focus back on MQA and experimenting with the Meridian Explorer 2. I'm wondering if for what follows it may make sense to jump and start a new thread. Anyone think that would be better than extending this one?

pro tem: The Explorer works OK with RISC OS and will light das pretty MQA light as well as it plays MQA material. Although it seems that it won't output from *both* the headphone and line sockets in parallel. As it has now controls I assume any adjustments would be via host machine software on Mac/Doze? Occurs to me to wonder if that is needed because a normal digital volume control would presumably mess up the MQA bitstream?

By default the USB descriptors list both 2byte/value and 4byte/value transfers with 2byte being first offerred. I wonder if that may lead to using the wrong one with some software, so again, wonder if that is dealt with my targetted means for Macs/Doze? I can fix that OK on Linux, but will probably just use default volume unless I can find a descriptor I can suss to control that. Default should be fine, anyway.
 
OK, I think this is the discriptors for the Explorer as listed by lsusb -v
http://jcgl.orpheusweb.co.uk/temp/explorer.txt
Initially I will just experiment with what can be done without attempting to alter the volume, etc. I can find out what is needed via ALSA. Once I've got some results that way I'd be interested in being able to contol volume, etc, as may be possible. I'll walk before I can try to run. :)
 
Certainly.

This thread contains most of the hard info on how MQA works. But as all MQA threads ... it still is 99% noise from both sides, spread over 900+ pages.

https://audiophilestyle.com/forums/topic/30381-mqa-is-vaporware/

That's probably the fate of any forum exploration. Much as happens on usenet, etc. On reason I end up writing my own conclusions on webpages so people can read that, then comment elsewhere as they see fit. But we can snip the 'pre-ramble' newcomers encounter if we now start a new thread.
 
Just a quick update: Looks promising. aplay plays both the MQA and 24bit non MQA files OK using plughw:

That seems from looking at the relevant /proc/asound files to play them S32_LE and seems fine for both. If so, the MQA will have any 'identifying' stream which is in the 16th bit of the 16bit file found OK when it is above two other bytes per sample. Seems OK also like this for Audacious. if so, makes life easier.
 
OK, I think this is the discriptors for the Explorer as listed by lsusb -v
http://jcgl.orpheusweb.co.uk/temp/explorer.txt
Initially I will just experiment with what can be done without attempting to alter the volume, etc. I can find out what is needed via ALSA. Once I've got some results that way I'd be interested in being able to contol volume, etc, as may be possible. I'll walk before I can try to run. :)
There's a volume control listed there. You should be able to access it using the 'alsamixer' or 'amixer' programs.
 
There's a volume control listed there. You should be able to access it using the 'alsamixer' or 'amixer' programs.

You've prompted me to read one of my old webpages!

http://www.audiomisc.co.uk/Linux/ALSA/ALSAforUsers.html

My uncertainty has been that I'm not sure if the gain changes they set may be done by ALSA rather than being an instruction to the sound 'card'. But I will experiment at some point once I've done 'as came' tests.
 
You've prompted me to read one of my old webpages!

http://www.audiomisc.co.uk/Linux/ALSA/ALSAforUsers.html

My uncertainty has been that I'm not sure if the gain changes they set may be done by ALSA rather than being an instruction to the sound 'card'. But I will experiment at some point once I've done 'as came' tests.
If you select the Explorer in 'alsamixer' it will operate that USB control directly. There is a softvolume module in ALSA, but it has to be explicitly requested.
 


advertisement


Back
Top