[Devodonaldson]

Just fixed it, will release an update today. Yes, it actually unfolds from 48 to 96. The second unfold can only be done by a MQA renderer like a AudioQuest DragonFly or iFi DAC. The 2nd unfold requires knowledge on the DAC used.

First of all, great work! My question is regarding the level of unfolds available to certain DACs. I see the v30 doing extra unfolds using its own decoder. Are DACs like the DFR and if xDSD maxing at 96khz, the unfold of the UAPP decoder? Are these devices unable to do the subsequent unfolds of MQA tracks in Tidal?

 

[Davy Wentzler]

First of all, great work! My question is regarding the level of unfolds available to certain DACs. I see the v30 doing extra unfolds using its own decoder. Are DACs like the DFR and if xDSD maxing at 96khz, the unfold of the UAPP decoder? Are these devices unable to do the subsequent unfolds of MQA tracks in Tidal?

In simple terms, the decoder does the first unfold, the renderer does the second unfold. MQA renderers cannot do anything with MQA unless it's decoded first. The DRF and iFi's do the second unfold when UAPP passes it's MQA decoded audio to the DACs. So in combination with UAPP, you will get 176.4 or 192 kHz (although you won't see the actual DAC rate in the UAPP display)

 

[Cooljazz669]

First of all, great work! My question is regarding the level of unfolds available to certain DACs. I see the v30 doing extra unfolds using its own decoder. Are DACs like the DFR and if xDSD maxing at 96khz, the unfold of the UAPP decoder? Are these devices unable to do the subsequent unfolds of MQA tracks in Tidal?

i have ifi nano idsd silver.It render max at 96khz.Dont know about xdsd.If you connect the xdsd to computer running Aurdivana you can check the bitrate form the ifi software.As for the DFR if i am correct it render max 96khz too.

 

[Devodonaldson]

In simple terms, the decoder does the first unfold, the renderer does the second unfold. MQA renderers cannot do anything with MQA unless it's decoded first. The DRF and iFi's do the second unfold when UAPP passes it's MQA decoded audio to the DACs. So in combination with UAPP, you will get 176.4 or 192 kHz (although you won't see the actual DAC rate in the UAPP display)

Ok. That's what I was wondering. V30 shows 176, etc. But USB DAC won't display higher than 96, though it will be?

 

[Davy Wentzler]

i have ifi nano idsd silver.It render max at 96khz.Dont know about xdsd.If you connect the xdsd to computer running Aurdivana you can check the bitrate form the ifi software.As for the DFR if i am correct it render max 96khz too.

No, both render at higher rates. The DFR can only accept 96kHz over USB, but the unfold is higher.

 

[Davy Wentzler]

Ok. That's what I was wondering. V30 shows 176, etc. But USB DAC won't display higher than 96, though it will be?

UAPP will show the rate at which it will output, it cannot know which rate the DAC is unfolding to. If the 'MQA rendering' color shows up on your DAC, then you know at least it is unfolding to a higher frequency.

 

[anttipi]

Nothing better to do at Christmas Eve I guess, so I did some testing and here is my final conclusion:
1) UAPP streaming from MinimServer library directly: all metadata is reported correctly in UAPP, hence track progress display works
2) UAPP streaming from the MinimServer instance offered by BubbleUPnP Server: metadata is not shown correctly in UAPP and track progress display gets broken

So, for some reason, metadata of files streamed via BubbleUPnP Server can be read by the Android BubbleUPnP app but not UAPP. Contrary to what I reported earlier, turns out it's not related to UPnP tethering, in other words, whether in mobile network or LAN it doesn't matter. I of course don't know if there's anything to be done to remedy this at either BubbleUPnP's or UAPP's end. I always thought "metadata is metadata" but obviously it seems it can get corrupted when streamed.

Apologies to Davy if my earlier conclusions (4G/tethering-relatedness) have caused some head-scratching while decorating the Christmas tree...

 

[Davy Wentzler]

Nothing better to do at Christmas Eve I guess, so I did some testing and here is my final conclusion:
1) UAPP streaming from MinimServer library directly: all metadata is reported correctly in UAPP, hence track progress display works
2) UAPP streaming from the MinimServer instance offered by BubbleUPnP Server: metadata is not shown correctly in UAPP and track progress display gets broken

So, for some reason, metadata of files streamed via BubbleUPnP Server can be read by the Android BubbleUPnP app but not UAPP. Contrary to what I reported earlier, turns out it's not related to UPnP tethering, in other words, whether in mobile network or LAN it doesn't matter. I of course don't know if there's anything to be done to remedy this at either BubbleUPnP's or UAPP's end. I always thought "metadata is metadata" but obviously it seems it can get corrupted when streamed.

Apologies to Davy if my earlier conclusions (4G/tethering-relatedness) have caused some head-scratching while decorating the Christmas tree...

That's ok.

But chances are low that the metadata is indicated incorrectly. Isn't BubbleUPnP just transcoding to a different rate?

 

[anttipi]

That's ok.

But chances are low that the metadata is indicated incorrectly. Isn't BubbleUPnP just transcoding to a different rate?

BubbleUPnP is set to transcode all files >96kHz down to 96kHz FLAC. Those files show up with their transcoded sample rate already at library browsing stage but are transcoded on the fly.

What I see in UAPP app:
1. All "native", non-transcoded FLACs, regardless of sample rate, are missing several metadata fields in UAPP (whereas they are visible in the BubbleUPnP app). This applies to both streaming directly from MinimServer or via the MinimServer instance exposed to the network by BubbleUPnP Server. The missing metadata fields are always the same for any (FLAC) file, like this:


2. The files transcoded by BubbleUPnP Server on the other hand always have full metadata visible in UAPP but "Duration" field is messed up. The transcoded files are always showing this exact same negative number in "Duration", see below (whereas in BubbleUPnP app "Duration" metadata is shown correctly):


I should note that only case 2 seems to present actual problems in UAPP, in other words resulting in the stuck-to-the-end playback progress bar and missing track length display. Even so, purely audio-wise things do work, just visually not.

 

[anttipi]

Deducing from the above: if UAPP were to ignore all erroneous, negative "Duration" metadata values it reads (and/or setting them as "00:00:00"), the issue could be circumvented? I'm no coder but the thought came up.

Edit: Uh, I see now all the missing metadata is loaded into UAPP at playback start, not before it when just library browsing. So the only mystery left is the "Duration" metadata of the transcoded files, which shows ok in the BubbleUPnP app but shows weird values in UAPP.

 

[LightBlue77]

@Davy Wentzler
I found a rather old but good sony android based dap, Nw-zx1. It has 4.1 android version. Do you think uapp will properly run on it? And will it detect and correctly use the internal hi res dap?
How about using Chord Mojo as external dac for a smartphone? Will UAPP detect it and properly use it?
Thanks.

 

[odessamarin]

I am also looking for best DAP with Android and Coaxial digitlal output, to use with UAPP..
can somebody advice what is a good candidate from your experience?
It's need good WiFi, Android and digital out (SPDIF)..
Fiio X7
Cayin N5ii
.. ?

 

[Davy Wentzler]

@Davy Wentzler
I found a rather old but good sony android based dap, Nw-zx1. It has 4.1 android version. Do you think uapp will properly run on it? And will it detect and correctly use the internal hi res dap?
How about using Chord Mojo as external dac for a smartphone? Will UAPP detect it and properly use it?
Thanks.

We may bump the minimum Android version to 5.0 in the near future, so I wouldn't do that. The NW's are not supported by the internal hires driver. UAPP does support the Chord Mojo though.

 

[LightBlue77]

Ok, thank you. You just made the choice easier.
I think Fiio is out of the list, i think both x5iii and x7(ii) have 5.x android so soon they will also be obsolete.

 

[Davy Wentzler]

Ok, thank you. You just made the choice easier.
I think Fiio is out of the list, i think both x5iii and x7(ii) have 5.x android so soon they will also be obsolete.

Well, the FiiO's are fine for another two years I guess.