advertisement


MQA

Status
Not open for further replies.
mansr said:
Viruses have a right to exist. It probably won't kill you, so you really should let it try.
Click to expand...
So let them try. Decode the 2L MQA files with your software decoder and publish them to be analyzed and heard.

Everything and the kitchen sink so as to not bring actual clarity to the issue in an honest and transparent way.
 
DimitryZ said:
So let them try. Decode the 2L MQA files with your software decoder and publish them to be analyzed and heard.

Everything and the kitchen sink so as to not bring actual clarity to the issue in an honest and transparent way.
Click to expand...
Smoke a joint, or maybe have one of those magic mushrooms
 
DimitryZ said:
The problem is the software decoder requires some amount of technical knowledge and I think access to a Unix platform.

MANSR wrote the software and he is an obvious person to decode 2L files. At that point either himself or others (yourself?) can analyze and compare them to baseline LPCM. Those audiophiles who are interested, can listen to both with non-MQA hardware.

So far all I read are reasons to not participate in this open and transparent process.
Click to expand...

FWIW I use Linux as well as RISC OS on a daily basis, and write simple programs for both. However I don't KNOW that the code Mansr has pointed to is entirely complete, correct, and signed off by MQA. It probably is, but that isn't knowledge. Nor am I certain I can impliment it without making an error. My programming skills are limited.

However if a DAC states it is compliant with MQA I can regard that as something they'd stop if it were false. And my interest at that point is in what comes out of such a DAC. And I do some experience with making measurements and assessing them. In addition I - as stated - am interested in what buying customers of DACs and source material may get.

I can't speak for Mansr any more than he can speak for me.

Your last comment again falls into the class which I think does you, and MQA, no favours.
 
Jim Audiomisc said:
However I don't KNOW that the code Mansr has pointed to is entirely complete, correct, and signed off by MQA. It probably is, but that isn't knowledge.
Click to expand...
The library pulled from the Bluesound firmware is almost certainly official MQA code. None of the code that I wrote has been so much as commented on by MQA, though I believe they are aware of it. Some of that code is just a trivial command line wrapper for the decoding library. Some other code parses parts of the MQA syntax but does no decoding.
 
Jim Audiomisc said:
FWIW I use Linux as well as RISC OS on a daily basis, and write simple programs for both. However I don't KNOW that the code Mansr has pointed to is entirely complete, correct, and signed off by MQA. It probably is, but that isn't knowledge. Nor am I certain I can impliment it without making an error. My programming skills are limited.

However if a DAC states it is compliant with MQA I can regard that as something they'd stop if it were false. And my interest at that point is in what comes out of such a DAC. And I do some experience with making measurements and assessing them. In addition I - as stated - am interested in what buying customers of DACs and source material may get.

I can't speak for Mansr any more than he can speak for me.

Your last comment again falls into the class which I think does you, and MQA, no favours.
Click to expand...
I am sure you understand that the code MANSR published is a hacked version of Bluesound MQA firmware. I am sure you understand that MQA certainly hasn't "signed off" on it as it's an unauthorized use of their partner's firmware.

You certainly can communicate with MANSRS to ascertain the status of his decoder. He has repeatedly posted links to it here and elsewhere, so I assume he considers it ready for use. You state that your interest is what comes out of an MQA DAC. I think a better question is to what is provided to the D/A stage in an MQA DAC (unfolded and rendered bitstream). This is what MANSRs decoder provides. It opens the decoding phase of MQA for analysis by engineers and hearing by those without MQA hardware. It seems to me an excellent opportunity to gain analytic and sonic knowledge.

Instead you have focused on the worst aspects of the system - undecoded content into a non-MQA DAC. Long discovered and reported, including by myself years ago.

Focusing on exclusively weak aspects of system performance while ignoring its primary intended performance configuration demonstrates bias.
 
DimitryZ said:
I am sure you understand that the code MANSR published is a hacked version of Bluesound MQA firmware. I am sure you understand that MQA certainly hasn't "signed off" on it as it's an unauthorized use of their partner's firmware.

You certainly can communicate with MANSRS to ascertain the status of his decoder. He has repeatedly posted links to it here and elsewhere, so I assume he considers it ready for use. You state that your interest is what comes out of an MQA DAC. I think a better question is to what is provided to the D/A stage in an MQA DAC (unfolded and rendered bitstream). This is what MANSRs decoder provides. It opens the decoding phase of MQA for analysis by engineers and hearing by those without MQA hardware. It seems to me an excellent opportunity to gain analytic and sonic knowledge.

Instead you have focused on the worst aspects of the system - undecoded content into a non-MQA DAC. Long discovered and reported, including by myself years ago.

Focusing on exclusively weak aspects of system performance while ignoring its primary intended performance configuration demonstrates bias.
Click to expand...

Polishing a
WFWo65Q.gif
is hard work.
I feel for you.
 
mansr said:
The library pulled from the Bluesound firmware is almost certainly official MQA code. None of the code that I wrote has been so much as commented on by MQA, though I believe they are aware of it. Some of that code is just a trivial command line wrapper for the decoding library. Some other code parses parts of the MQA syntax but does no decoding.
Click to expand...
You reported earlier that your software does both unfolding and rendering, finally extracting LPCM bitstream that would go to the D/A stage inside the MQA DAC.

Therefore, the result from an MQA file played through MQA branded DAC is equivalent to an MQA file decoded by your software and played through a non-MQA DAC (with some DAC to DAC variation).

Publish the files so the competing bitstreams can be analyzed side by side, best to best.
 
Rosewind said:
Doesn't alle Americans have the right to plead the Fifth? Perhaps it is time to do so?
Click to expand...
In mid 90's, we were in Helsinki and went to a local bar, where a guy had everyone in stitches impersonating self-important, ponderous, droning Norwegian speech.

You must fit that caricature. Don't you have a long-winded, thunderous poem to write?
 
EDITED
Don't feed the trolls.

It is very interesting that Archimago, Golden One, mansr and Jimaudiomisc arrive at similar results. So far I have seen zero real life counter-evidence from the pro-MQA'er who so valiently keeps ploughing ahead.
 
Rosewind said:
EDITED
Don't feed the trolls.

It is very interesting that Archimago, Golden One, mansr and Jimaudiomisc arrive at similar results. So far I have seen zero real life counter-evidence from the pro-MQA'er who so valiently keeps ploughing ahead.
Click to expand...
That's because your heroes CHOSEN not to give you any (they only present MQA into non-MQA data) and you CHOSEN not to listen to actually decoded content. So you remain ignorant, by their choices, but also your own.

Analagous to an automotive journalist reviewing a sports car and reporting ONLY on its bad performance on the snowy streets - and never reporting that it's actually very good on the track. If you never test-drive it on the track or read another review you will be convinced it's a terrible sport car.

Choices and consequences.
 
Status
Not open for further replies.


advertisement


Back
Top