Current DAC is S.M.S.L D-6s. Audirvana seems to detect it as MQA decoder.
Resulting in what consequences regarding proper MQA handling?
Most likely because Audirvāna doesn’t apply DSP to 705.6kHz and 768kHz files… So the MQA metadata is not modified at all and passed along to the DAC as the first unfolding of the MQA processing.
OK … Second attempt to ask you my question:
Will an upsampling setting »Power of Two …« allow for proper MQA handling or will it make proper MQA handling impossible?
Regarding Audirvana’s settings panel:
Should any greyed-out instance regarded as being completely uninvolved in the current process? See the red marked parts of the attached screenshot: Should/can they all six be regarded as completely in-active in the given situation?
They should be completely inactive in this situation.
It’s what I thought, but I need to reproduce this on my end.
It appears that you have an illogical ‘Custom’ strategy that may be playing into this weird behavior…The strategy appears to up-sample 44.1kHz files to 192kHz, which is not a logical target… Why this would have influence…? That’s a good question if in fact, that illogical strategy is the culprit… (When up-sampling is disabled)
To get a baseline reference..
What happens when you set the ‘Custom’ strategy to the default values?
- 44.1kHz → 44.1kHz
- 48kHz → 48kHz
- 88.2kHz → 88.2kHz
- 96kHz → 96kHz
- 176.4kHz → 176.4kHz
- 192khz → 192kHz
Or a logical strategy as below…
- 44.1kHz → 705.6kHz
- 48kHz → 768kHz
- 88.2kHz → 705.6kHz
- 96kHz → 768kHz
- 176.4kHz → 705.6kHz
- 192khz → 768kHz
Happens to be BS.
- Garden variety FLAC works as well if not better.
- High resolution audio is a niche market that is a tiny fraction compared to mp3 streaming, let alone streaming television like Netflix or YouTube (ironically owned by Google, whose AI expresses such concern about the relatively trivial amount of hi res audio streaming).
Feel free to listen to any format
@Antoine @Audi100 @Derek
This behavior has been bugging me…
Something is going on with the MQA decoding processing in Audirvāna… I am guessing here, but it appears the operation is looking at the up-sampling configurations and reacting to the logic applied… What we do know is that the first unfold is typically not allowed to be up-sampled beyond 2x the base-sample rate result… So if this is the case, ‘Power of Two’ in the context of this particular DAC capability, would be prohibited because the 768kHz result would violate the 2x restriction… In the case of the ‘Custom’ strategy, the result falls within the 2x restriction window and allowed, and as a result of the bit-depth and sample-rate conversion, the MQA metadata is destroyed. I think we can presume if the ‘Custom’ strategy is set to “one-one” defaults, OR if no up-sampling algorithm is selected in any scenario, there would be no processing applied and the first unfold signal will be passed along with the metadata intact.
Based on this simplified overview (below) of the MQA decoding processes, I presume in the case of this particular encoding, that within the architecture of the MQA encoding process the first unfold is the MQA 24/192kHz reference file with the metadata instructions needed for proper playback in the specific MQA DAC architecture. 
Where the latter would just be a big fat bug, I’d say. Not further reading necessary beyond that point.
Maybe it was never considered that folks would ever apply up-sampling DSP to MQA files… Have you tried selecting “None” as the ‘Forced Upsampling type’ ?
You obviously don’t understand. Any DSP settings I did have been done based on the (obsolete?) certainty that they would be bypassed during MQA and DSD processing.
This appears yet again a conundrum for folks committed to MQA files… I suggest not investing in these today and in the future, as there are new variants on the horizon that may obviate MQA streaming rationale for content providers. MQA labs has a plug-in that post-processes a file to customize or eliminate the time-domain artifacts…
DSD playback, yes… primarily because of the 1-bit PDM signal, but MQA is a different animal…
As you can see, you have other DSP process disabled and they do not affect the MQA file… So, if you have ‘Forced upsampling type’ set to “None”, we would expect the MQA file to be unfettered.
I’m not saying that the MQA decoding operations in Audirvāna are functioning properly… I don’t have enough insight into the strategy they are applying, and/or in the context of every MQA encoding, because there are variations on the mastering processes for transmission priorities…
Maybe the ‘simple’ solution for MQA file playback is to automatically prohibit/block the enabling of a ‘Forced upsampling type’ and provide a warning message and options to enable up-sampling if the DAC is not MQA capable…?
We appriciate your input on solving this complicated matter
I’d guess that neither @Antoine would say so.