AudioQuest adds MQA Support to Dragonflies via firmware

[PeterSt]

3 hours ago, Gonzbull said:

Theres commonly 3 sets of ADCs used. 1st when recording, 2nd when mixing and 3rd when Mastering.

 

I start to understand better why music recordings may s*ck these days.

[PeterSt]

So ... Either of this (or all) is happening :

 

 

A. Mr Rankin is not under MQA-NDA and makes up more than we can do all of us together.

 

B. Mr Rankin didn't understand anything of what he has been doing / attempting.

 

C. MQA is hoaxing all of us, including me, but not Mr Rankin.

 

D. Everybody is genuinely co-operating, but the DF just doesn't work as intended and nobody notices.

 

 

Have fun with this multiple choice. Maybe I overlooked possibilities.

[PeterSt]

Gordon, glad you took the bait instead of someone else, which may have gotten out of control (I know, my fault).

 

8 minutes ago, Wavelength said:

It's one of the reasons I don't frequent here more often.

 

I fully understand. I really do.

 

The problem I have with your explanations - more than you may have wanted but also more than I can justify, is that, well, I would disagree with about all. And the funny thing is, I should know too ...

No, I am not owning a Dragon Fly, but I do design DACs with lights on it with all sorts of colors. 

 

16 minutes ago, Wavelength said:

C. MQA is hoaxing all of us, including me, but not Mr Rankin.

 

D. Everybody is genuinely co-operating, but the DF just doesn't work as intended and nobody notices.

 

I think the above options remain.

 

FYI, I am pro MQA as you are, with the difference that the options you seem to have available are different from mine. So see ? something ain't matching up.

 

You kind of apologize (my wording though) that the DF needs the core decoding in front of it. This is the most peculiar because that is what I beg for but don't get.

Funny eh ?

 

[PeterSt]

1 hour ago, Wavelength said:

Also I am sure MQA would appreciate it if you would not prod questions like this.

 

Yes Gordon, and my biggest "con". But I have the idea you started this now.

 

E. There can be software decoding all right, but no filtering or whatever DSP is possible.

 

Say that I forgot that option.  Actually I forgot it because it is too obvious that anno 2017 such means are more or less a requirement.

So you see, this renders our MQA decoding software useless (which is for 50% about its filtering) and this also renders our Phasure DAC useless, which is NOS and with the assumption that NOS DACs require filtering of any kind (call me strange).

 

So here I am ... XXHighEnd (Windows) decodes MQA but no MQA rendering is possible behind it. Far away with the option that a NOS DAC stays that (NOS instead of MQA filtering), but it always requires the software to pass through. But see my little list :

 

 

MQA Decoding software with nice filter -> MQA Rendering DAC <- Impossible.

 

MQA Decoding software with volume control -> MQA Rendering DAC without VC possibilities (no VC anywhere) <- impossible.

 

MQA Decoding software with nice filter and VC and DSP and what not -> Non-MQA rendering DAC <- Possible but moot because software can't run on MQA DAC.

 

MQA Decoding software without any processing -> MQA Rendering DAC <- Possible but no market (not any more and of course my subjective opinion).

 

Non-MQA Decoding software  -> MQA Decoding DAC without rendering <- Possible but probably not allowed by MQA (didn't investigate that). Is moot anyway.

 

Non-MQA Decoding software without filtering or other means of VC and DSP  -> MQA Decoding and Rendering DAC <- Possible. But no market these days.

 

Non-MQA decoding software with filter or VC/DSP -> MQA Decoding and Rendering DAC <- White light.

 

MQA Decoding software with VC which controls in-DAC VC -> MQA Rendering DAC <- Possible and maybe there is a market for this. This should be the way the DF works.

 

MQA Decoding software with VC which controls in-DAC VC -> MQA Decoding and Rendering DAC <- Possible and maybe there is a market for this.

 

 

Regarding the last option, I am not so sure whether it is possible that such a DAC optionally will be able to bypass the MQA Decoding stage. I mean, who depicts that such a DAC will have this option. So if not, said software will be useless again and it depends on the DAC it runs into.

 

 

I don't think this is information which can harm MQA and it is the truth of functional outcome anyway. Besides that it is clear that readers mostly lack this knowledge, so I hope this helps someone.

A lot is about the lack of a pre-amp or other means of analogue volume control. So if I refuse to use such a (in my view) detrimental means of VC, I am completely stuck from various angles. But it is the combination of everything (see list above).

Thus believe it or not - I have everything running here, also the hardware. But because of the lack (or my refusal) of using a pre-amp, I G-D never heard one note of full fletched MQA (meaning : I can't use the renderer part or else I lack the VC or the filtering or whatever I do and like to do in software).

 

Thanks for listening,

Peter

 

Edit :

PS: If my list is wrong or incomplete, I have to apologize. But let's make it correct then. Thanks.

[PeterSt]

5 minutes ago, mansr said:

The metadata in the decoded stream sent to the renderer includes a gain parameter. If this is set, the renderer applies software volume control. I don't know if this capability is a hard requirement or if MQA would certify a renderer that ignored it.

 

That would be this option :

 

18 minutes ago, PeterSt said:

MQA Decoding software with VC which controls in-DAC VC -> MQA Rendering DAC <- Possible and maybe there is a market for this. This should be the way the DF works.

 

As far as I know this is optional. But easy to be wrong.

[PeterSt]

Gordon, thank you for a kind reply.

 

4 minutes ago, Wavelength said:

E? I am a little confused... I take it your talking about DSP filtering before it hits the DAC or between the render application and an MQA capable DAC and the interface (

 

The former.

The latter is a bit difficult to judge as you call it "render application" (haha). Anyway, the DSP etc. can also be in-DAC, but this is not my stihl hence I regard this "old fashioned". In-software is the way to go - is more flexible as well (just a strategy).

 

7 minutes ago, Wavelength said:

Peter, you can design into your product analog volume controls like others and myself have done and over endpoint 0 have a system wide volume control. There are many ways to do that actively and passive

 

Sure ! But in my view there's one good way only, and this requires another DAC (chip) setup.

At this moment I like to continue the NOS1a DAC.

(I have suitable designs with voltage control, but they are not exactly NOS as such (but SDM based)

 

9 minutes ago, Wavelength said:

Peter, you could also entertain having digital filters and a NOS DAC. Remember digital filters were originally conceived for Low Pass to remove all the unwanted crap. But remember MQA might be using Filters that are not of that typ

 

Gordon, yes. And they can be in the MQA compliant DAC just as the (standard) filters in there can be bypassed all together.

And now I like a code example ...

 

11 minutes ago, Wavelength said:

If you wanted to do MQA, I would talk to them and see what they have to say.

 

I can be the most wrong, but I think MQA never had the situation and question at hand other than from me.

So what I want / need, for sure can be done (but it is a bit of digging).

I now need to emphasize that I don't expect the people from MQA to give this small boy any priority over the big players, although it starts to look like I currently have the only MQA capable player for Windows (Tidal or offline). Anyway, I hate to give reminders to people who for sure are busy enough before they have some spare time to investigate how to actually use the API regarding this. But as said, I can be wrong (but don't have the answer anyway) and maybe I should give them a call again. Or spend more time on it which I am always in lack of ...

 

Regards and thanks for the heads up,

Peter

[PeterSt]

5 minutes ago, miguelito said:

Consider the Dragonfly's ESS DAC: It does not know anything about MQA, all it does know is to set specific upsampling filters as instructed by the microcontroller.

 

You must be a bit careful with this ...

As I understand, the DF doesn't go beyond 96KHz anyway, so there is not much to upsample, assumed the original file was 96KHz (or 88KHz).

This, while upsampling is also a possibility (by MQA hardware). But I think this is completely outside the subject.

 

To be hopefully more clear : the "upsampling filters" as you mention them are nothing of the kind when we'd talk about reconstructing the native 96KHz (etc.). Let's call that "unfolding process" and you're at what it is.

And this works up to 384KHz (or 352.8 more practically (DXD like from 2L).

 

I could also say : the filtering which can be disengaged (in-DAC) can be externally controlled. This is something very different from adding our own filtering (which is upsampling at any event !) in-DAC. Envision that I talked in this realm when I said "replace the MQA filters by our own" (similar). Thus :

 

MQA Renderer (is in-DAC) -> Our digital Filter -> D/A Output.

 

which would be very similar and more easy to understand :

 

MQA Renderer (is in-DAC) -> Our digital Filter chip -> D/A Output.

 

... because that already feels fairly normal.

But in "modern days" we don't like to approach it like that because we go for option A the least, and actually better like the HQP / XXHighEnd solution which is in-PC. And now nothing works ...

UNLESS in-PC the rendering can be done.

Tadaaa ... (for those who adhere MQA)

 

 

 

[PeterSt]

5 minutes ago, DarwinOSX said:

You are never going to get PCM streaming

 

What do you mean by that ?

If it is what I think, I wouldn't put money on it ... 

[PeterSt]

13 minutes ago, miguelito said:

88 or 96 to 352 or 384 is upsampling in the ESS DAC. The MQA embedded data that the microcontroller decodes tells the ESS DAC what upsampling settings/filter to use. There are no MQA owned anything in that DAC.

 

Maybe I am unsure what you mean by the latter ("owned") ? language problem ...

If you only know that MQA can unfold to 384 when the file natively is that.

Uhm ... don't ask me how that would work when still the transport (stream) is 44.1 or 48 but it is a typical thing I take for granted. Anyway it is not upsampled.

This, while upsampling to max 384 is a feature of MQA.

 

I suppose you are saying that the DF just doesn't go beyond 96. Fine. But this is not related to MQA's capabilities (and upsampling as such I don't call a capability to begin with, but alas, it can do that too).

[PeterSt]

5 minutes ago, DarwinOSX said:

Psychoacoustics is definetly perception and that can differ greatly of course.

 

If we only (all of us !) could count that out ...

[PeterSt]

2 minutes ago, DarwinOSX said:

I mean no streaming service is going to adopt PCM as a format.

 

Still unsure what you are trying to tell.

MQA is PCM ...

[PeterSt]

3 minutes ago, DarwinOSX said:

What is typical PCM file size?

 

For streaming ? does not matter. For bandwidth, yes. But bandwidth is no problem either. And if not today, then tomorrow.

Anyway, what I was suggesting is that even 384 wouldn't be a problem. But it depends on the software ...

[PeterSt]

5 minutes ago, miguelito said:

So in other words, MQA is ALWAYS decoded in two steps:

1- Unfold to 2x rate

2- Post-process to target rate

 

Completely correct. But this doesn't mean that #2 is upsampling.

Upsampling = fake. And this is not what MQA provocates (same as a native 96 file which is unfolded to that, taking distance from how lossy that is or not). OK ?

[PeterSt]

7 minutes ago, miguelito said:

You're taking too many things for granted, methinks...

 

Haha no. I am trying to utilize all the diplomacy my father ever put into me. But I am not much used to that (as people may know). I am dutch as well, so that's an extra handicap.

 

LOL

[PeterSt]

12 minutes ago, DarwinOSX said:

Streaming via a carrier matters for data usage, bandwidth, and performance. i.e. no stuttering.

We all know this.

 

Of course. But it will disappear (any modern world will make it flat-fee).

And the no-stuttering ... ah, it is something I can guarantee (at any low bandwidth). But never mind, you point is clear.

[PeterSt]

12 minutes ago, mansr said:

The original high frequency-content is simply not stored anywhere in the file, so there is no way to reconstruct it

 

And you think that for 96 it is ?

(you can respond of course, but I'd have to stop right here)

[PeterSt]

6 minutes ago, Wavelength said:

Hey it's been great here for the most part. I am going to leave now.

 

Gordon, let me be honest ...

 

No matter the way I challenged you, for me this felt back to 2008. An eventually civilized conversation with respect. I am not even talking about myself. But it seems to be as easy to join as the other POS.

(just invented that one, so guess)

 

Regards,

Peter

 

 

[PeterSt]

@Jud I can't help it that the official documents are so clumsy to talk about downsampling and upsampling, but I'm afraid that the downsampling can not be avoided (that is just what it is) so to call the reconstruction upsampling is almost a logical thing. Or call it deconstructing (oops) and reconstructing.

 

Anyway you got my thinking right. And this includes the impossibility of judging what the real merits of matters are. Maybe it helps if I say that I did not express an opinion, but a translation of what's expressed by MQA. So no matter what one might like to read in/from the Patent(s), officially there is a (code) difference between unfolding to the original sampling rate and upsampling further from there.

Easy to get mixed feelings about my drifting between what is and what should be.

 

 

[PeterSt]

On 2017-5-27 at 2:39 AM, ShawnC said:

Here's Han's review

 

Oh that Hansss.

If I had known that it was him I would have looked into that right away ...

... to see what non-sense he came up with this time ...

 

Some times I feel I need to apologize to live in this country. 

[PeterSt]

On 2-11-2017 at 7:38 PM, GUTB said:

If you can't hear the MQA version is better I don't know what to tell you.

 

I coincidentally agree. The Redbook shouts too much. With the MQA you are waiting for when this happens but before you know it, the track played all through.

Not sure whether this is representative for MQA (the MQA version is more compressed, which this one seems to need), but the "into the mouth" certainly is in order for this one too.