Hi Arvind, not really another question because I already talked about that. This definitely should work (was explicitly made fort it), also should still work (while things changed) but testing I am not going to do because I don't know examples. And the minute you do know them, you will have tested it yourself, right ? 

Short answer to your question : Yes.

Regards,
Peter

Hi Nick,

Nah, the contrary. Unless you call 2-3mm (to one side) relatively large of course.


It is 19Hz, but that does not matter. What does matter is if you really "think" the excursion is to be relatively large, then you are playing right in the distortion region. Because it just can't excur largely or else you'll just *have* the distortion.
Assumed this is your case (and you thus overblow the bass to begin with) something else is going to happen :

It now takes "nothing" to cross the border of distortion vs no distortion and even the slighest change in response will alter the audible SPL largely. It is a matter of e.g. 22Hz barely audible (but you will feel it) with no distortion vs a 2nd harmonic (44Hz) getting profound and of which you still think is is "sub low". You just wouldn't know the difference when this kick drum is playing, because it would produce both 44Hz and 22Hz (it goes down in the "ambient" to ~20Hz). So really, 0.2dB of output change in level may incur for 20dB of audible SPL (2nd harmonic distortion) easily. It is a very slippery slope there.

Do notice that the sheer fact that you mention a required "relatively large excursion" tells me all.
And let's also keep in mind that the speakers are rated for 19Hz without audible distortion (meaning that you will hear zilch of 19Hz) when the SPL (of 19Hz) is 89.

Hope this helps !
Peter

Hi Arvind,

I will check that album, but do notice that it exists that tracks of an MQA album can be non-MQA. I'd say for a normal artist (like CSN&Y) album this is rare but for collections or Playlists this can easily happen for sure.

What I am not sure about at all, is whether XXHighEnd still deals with this properly. So Zheng already reported a "too slow speed", and now you do too, while I never experienced that (and it shouldn't be). Small problem : all my albums have been prepared with the decoder active at the Music Server (Tidal) PC and such a thing can only (?) go wrong with new Preps. Anyway, I will do so with Deja Vu and let you know (later today, if I don't forget).

Kind regards,
Peter

From https://ifi-audio.com/portfolio-view/nano-idsd-bl/ :

For mobile DACs with both portability and power considerations, MQA Rendering is the ideal solution as the workload is shared between the host (computer) and the client (DAC). In this case, for a DAC such as the nano iDSD BL, less CPU processing and lower electrical power are needed. This approach for the iFi portable range remains a full end-to-end MQA solution and the listener still enjoys the full benefits of MQA without compromise.

What's this about is that this iFi can act as a Renderer only or as a Decoder plus Renderer (this is elsewhere in the text). The responses you received form tech there are about it acting as a Renderer only, with upside down advices.
But also see what I put in bold in the quote above; there's nothing portable that can decode MQA (yet) so with the example of the Tidal Desktop App (which is a Windows application and which can Decode MQA indeed), there's nothing really much left of the portable part.

British vaporware !
haha

You really make me laugh here !
But let's say it is not easy and one of the harder parts is making clear what the status is, where. In XXHighEnd this is about the Native Sampling Rate (shown in the Hires Audio little logo), the fact that it is MQA to begin with, whether it is decoded or not (just FLAC logo instead of MQA logo) and whether Blue or Green (or even Black, but never mind that). Or nothing because something is wrong. Or how the Native Sampling Rate can just be 44.1 or 48 only (no unfold anywhere).

And let's be honest, in XXHighEnd were problems because
- a PC nog being able to decode;
- I change something so the Tidal connected PC does not need to decode at all, and next the solution for that gets buggy (2.10 vs first 2.10a and next 2.10c - the latter hopefully right).

Also, a major part of this all is that nobody really understands what can happen at the user's side.

Answer: Typicall those albums are encoded as 48kHz MQA file.
Correct.

Meaning Tidal will perform the decoding to a 96kHz audio stream
Also correct. But not with MQA Passthrough ACTivated. But OK, it apparently is their assumption that Tidal will do the decoding :

with the MQA renderer handling the further decoding
Uhm, the Renderer resides in the DAC. Is that not the case with iFi then ?

which this has nothing to do with our products,
Ok, so it does nothing. You are right, it is vaporware.

To test that the actual audio stream in TIDAL is 48KHz please select "MQA passthrough", it is 96k if TIDAL decodes MQA, it is 48k on MQA pass-through.
Although the construction of this sentence is lousy, the bold part without further context is correct. The construction of the sentence is NOT lousy if they don't understand how it works. Apparently they take it that Tidal (desktop) can still decode MQA regardless. Anyway, this should have been written like this :

To check that the actual audio stream in TIDAL is actually 48KHz (it always is, unless 44.1) please select "MQA passthrough"; if it is 96k something clearly is wrong and decoding takes place ahead of our converter and now it can't render (further 2nd and 3rd unfolding)[/i].

...

Answer: Yes, meaning it was MQA encoded from a 192KHz remaster.
Initially nothing seems to be wrong with this. But mind the little bold part. Clumsey expression ? Let's say it is that.

You know what I think happened ? iFi implemented a green and blue/purple light, does not do a thing more but doesn't even understand that.
But could that be true ? it seems too far out ...

Peter

... At least that looks opposite (upside down) to me.

a. MQA Passthrough, what should it mean according to iFi ? My idea about it : don't decode, pass on to Decoder further down the line (but the video shows opposite).

b. Green light instead of blue (or purple-ish), what should it mean ? -> File is MQA Authenticated, but not signed off by the artist (et al) (but iFi hence video shows = PCM).

About your own text in your previous post I must think a little ...

Peter

Hello Zheng,

I just quoted a kind of random sentence from your last posts because I am not sure how to approach this all. One thing is in my mind though : your iFi isn't behaving as should. But how to prove that with my own software which (apparently) can also do a couple of things not right. But point is : you now have a way inconsistent situation. So to me that tells something (to you nothing, I  am afraid).
It is almost like your iFi can't do the 1st "unfold" but can pick it up like MQA because XXHighEnd now is taking care of that part. All seems "opposite" ...


This one is different; So as we know, I now take the FLAC header as the base and if this header doesn't tell it is MQA, then it won't be decoded as well (by XXHighEnd, I mean). If the header tells in the right way it is MQA, then it stil depends on the content, so XXHighEnd legally (read : "authenticated" (ahum)) decodes MQA ot not.
But 2L already has proven in the past that they don't comply well to header data (XXHighEnd contains exceptions for 2L (but also for many more)), so what if this is wrong now. So at this moment (and before I report back about this) I would NOT use 2L for testing whether MQA works or not.

Also be careful : MQA can be downloaded from 2L. This will NOT work in XXHighEnd for MQA decoding. Only the Preparations from Tidal will ...

Regards,
Peter

So Nick, what I actually scratched in my initial response of the bass is that I have spades of more sub low now. I of course fully agree with the second by me bolded sentencem but for me it went the exact other way around. The whole room is energised because of this and because of *that* the hihgs can bear much more (so this effect is opposite of what I said in my previous post). It also implies/creates the abnormal transparency.

But our systems can not be compared.
So I don't want the "I have the better bass" guy, but I do need to point out that consistency for relative changes, is crucial. So once more : If I change my SFS from 10.19 to 5.19 this seems to be out of context of anything else. But it is all about the combination with Q1 of 30x40. Don't do that and nothing new or special or anything is there about any ".19" SFS setting. Well, that is what I think ...

Peter

Hi Arjan,

I only wanted to add to this that this is not a real fair proposition, were it about more bass as such. What the Q3=0 does (I also noticed the Q3,4,5 = 0 in Nick's sig) is that it takes down a level of detail and with that crispyness, which indeed will make the bass more profound, but thus in a somewhat illegal fashion. Take out all the treble and your system will be way bassy. But no bass was added as such.
Btw, someone else just said similar and I only want to emphasize that your Q3=0 does that.

What I should also add in the same context, is that Nick is a real "bass heavy" guy. He will have set his Q3,4,5 all at 0 emperically found for that very reason. This is a matter of "to each his own" but in the mean time it is a bit hard to communicate over matters.

Btw, Nick nicely and rightfully announced that his system can't be compared to others and actually I should do too (in either situation I am referring to the Audio PC).

Best regards,
Peter

Hi Nick, sorry to disturb you at this inordinate time  , but assumed your sig is up to date, you don't "comply" to anything much we are talking about. So, Arjan gives you an advice here, you say that you wil try it out, but meanwhile about all of your other settings are not consistent by miles with what we are talking about. And please notice that this started in the (your) 2.09 topic (somewhere under way, by me myself) and from there all was worked out in more detail.


So that. This is super crucial because it is all about the combination of the large buffer sizes with the low SFS (this hasn't been done in 10 years until recently (2.09).


I think this is crucial too and it resembles my remark about this, I think still in the 2.09 topic or maybe it was 2.10 already) that I used 41 (which works since some W10 build) but which I found later to have dreamt because my system was at 52. So I re-applied that to my sig (after having changed it to 41 the same day). This 52 is probably wrong (creeped into it because of RAM-OS not saving because of whatever (power) failure) with also the notice that I don't even use that system at this moment. Long story short : at this moment I have more trust in Richard's findings than I have in my own memory. And btw, in the system I *am* using at the moment, the Balanced load is at 18 ... (this implies 380MHz and less it can't bear (stutter)).

Best regards,
Peter

Hi Arvind,

The input to XXHighEnd - as a software player - is correct. This is always the Native Sampling Rate as how it is denoted in the file itself. You can see it like this : the file as how it comes from Tidal first needs to be decoded, which means "expand" it to the first "unfold", if present (native 44.1 and 48 files also exist and they don't have a 1st "unfold" stage). When that 1st "unfold" has been done, it is given to the player (XXHighEnd) which thus sees 88.2 or 96 (and that XXHighEnd is applying that decode step herself may be confusing but say that it happens right in front of XXHighEnd).

Software can never "unfold" more than to 88.2/96, which is why you never will see a higher input to XXHighEnd.

What I noticed in your system is that you set the upsampling to 1x. Thus now e.g. 96 stays that (I think you set it to 2x but with the fx button active but for 88.2 and 96 it comes down to the same - you won't upsample to 192 and beyond.
I would set 16x there, as usual (this is up to you of course, and I am only telling to ensure that you understand the process).

If we regard the 2nd and 3rd "unfold" to be upsampling steps anyway for MQA (and I do) then you now do this yourself. One thing : I did not build a formal "till there and no further" mechanism, or IOW, there is no such thing as allowing you to upsample to the "native" Sampling Rate as MQA depicts it (in the file). You can only set 2x, 4x, 8x or 16x. Well, you just set there what you were used to (and I'd say this is 16x).

Try to keep in mind : while 2nd "unfold" and beyond is an upsampling step anyway in an MQA DAC, you now apply that upsampling step yourself with the difference that you use your own filters (within limits of course). Would you not have a NOS1 DAC but an iFi etc., then in such a DAC filtering is applied which you can also overrule by XXHighEnd to some extent. This is not related to MQA at all and always has been so.
Today though, people may get easily confused by their MQA capable DAC (like Zheng's iFi now), that seemingly working very differently. But all such a DAC does is enable a 1st "unfold" which can be done in software just the same (100% the same) and next apply filters which also can be done in software (but with different filters like always) for further upsampling. It is this latter which you have virtually switched off, by setting 2x only.

For Zheng : IIRC he does not upsample/filter in the first place. So he has set 1x (if all is right). This is everyone's good right and in fact you tell your DAC to take care of the filtering all the way (and would one have a NOS DAC then NOS is used as ever back intended ("filterless")). However, when Zheng sustains this 1x setting (already required to decode MQA by his MQA capable DAC) he is comparing apples with orangeswhen he would compare MQA done by XXHighEnd v.w. MQA done by his MQA capable DAC. Why ? because with 1x in XXHighEnd always, he will compare the iFi filters outside of MQA (no MQA file playing) with the filters within MQA (MQA file playing). He now actually compares two different DACs. Would Zheng upsample 4x because his native iFi can do that for non-MQA files (plays 192 (or can it do 384 ?)) and set to 1x to MQA files, he will compare XXHighEnd filtering with MQA filtering. BUT, would he play MQA through XXHighEnd and upsample 4x he would compare MQA playback through XXHighEnd with MQA playback through the iFi. This latter sounds the best apples and apples to me (I know, it still isn't).

Btw, look at the title of this topic. Funney eh ?
So it is all stupid stuff which is almost impossible to uderstand. A decoding problem ...

Peter

Hi Zheng, yes, I have been struggling with that text a bit. I now changed it again.
It went wrong when a 2.10a which was in there at first, was changed into 2.10c.
Thank you for being corrective !

Peter

For some reason I have more bass than ever. Haha.

Regards,
Peter

Dear Zheng,

Can you please re-apply all of your testing with 2.10c ?
Quite a lot of things were not correct with the "FLAC header determination" (as seen from Arvind's installation).

Regards,
Peter

2.10c has been uploaded to the 2.10 topic.

This is only needed for the Audio PC. Unless you are used to play (MQA) music on the Music Server PC; then it is for that one (too).

Peter