Interesting… Well, it will be interesting to know whether Roon actually displays “24 bit” as acknowledgement or verification of 24/48 unfold, or if they just echo metadata content to the display…I sure hope not. It could also echo metadata on assumption of a low fidelity “successful” status from an unfold module. Programmers have been known to interpret successful differently, or use simpler short circuiting logic as opposed to raising a variety of exceptions that might convey that the expected result did not occur. Hey, it didn’t crash…success!! LOL, deadlines and everything.
All wild guesses and speculating around…I obviously have no idea who develops which pieces, and what protocols are supplied to all of the MQA licensed partners. Just interested in the truth about MQA, and satisfying my (former) software engineering troubleshooting mentality.
BTW, all of the ELP 24/96 MQA Masters are coming to the FPGA display as 24/96.
Evidently humor has been sucked from the world- of course there is an issue if Roon is reporting 24 bit output and the Bridge says it is 16. I’m sure our fine folks at PS Audio will straighten it out as soon as they can
Sorry - it was early and I have been looking forward to this for a while - but I agree - humour is needed and appreciated.
Keep in mind the DS never sees the file as FLAC, only as PCM. It has no way of knowing in what format you stored the file before it is played back and decoded by your player/server.
Paul, you have my gratitude for the resources you’ve brought to bear for us here and the results you’ve rolled out. My system has never sounded better. You’re grooming some mighty customer loyalty here.
The issue of 24/96 displaying as 24/96 while 24/192 displays as 16/192 was definitely happing in Mconnect. Not unique to Roon with Bridge II.
There is quite a handful of albums on Tidal with three versions available: 16/44, 24/96 MQA, and 24/192 MQA (which displays as 16/192.) I spent some time doing back-and-forth listening on three different albums last night, and my ears preferred the 24/96 MQA in all three.
If a janky free app like Mconnect can designate MQA albums with a little M on the cover art, why can’t Roon pull this off? When I see three different versions of the same album, I have to play each file to see how it displays to find out which is which.
These developments are making the holidays a lot more fun. Thanks again, PS Audio.
If a janky free app like Mconnect can designate MQA albums with a little M on the cover art, why can’t Roon pull this off? When I see three different versions of the same album, I have to play each file to see how it displays to find out which is which.
Probably a comment that should be posted to the Roon forum, as there is nothing PSA can do about this. However, one approach I’ve used to work around the issue is that I browse the Masters list periodically in the Tidal app (which has no filtering or sorting capability once you get into the Masters - major Fail!) and I mark those albums I’m interested in as Favorites. Then from Roon, I can pull them up as Favorites and know without an icon that they are MQA versions.
Hi everyone. I’ve updated the bridge firmware even before the dac, maintaining it with Huron, and the 16/24 bit information problem seems to be reserved only to 192k MQA files. Just my two cents.
cymbop said
4) If a janky free app like Mconnect can designate MQA albums with a little M on the cover art, why can't Roon pull this off? When I see three different versions of the same album, I have to play each file to see how it displays to find out which is which.
Probably a comment that should be posted to the Roon forum, as there is nothing PSA can do about this. However, one approach I’ve used to work around the issue is that I browse the Masters list periodically in the Tidal app (which has no filtering or sorting capability once you get into the Masters - major Fail!) and I mark those albums I’m interested in as Favorites. Then from Roon, I can pull them up as Favorites and know without an icon that they are MQA versions.
I used a slightly different approach.
I created a playlist for each artist with good MQA recordings…I preface the playlist name with “MQA”, for example “MQA - Herbie Hancock”.
I’m sure Roon has more than just a few people poking them about an MQA visual cue.
If there is a problem in the Bridge code we’ll investigate and fix next week (well, we’ll investigate next week it often takes more time to fix.
The problem is not in the bridge code. I'm seeing the same issue via USB too. I was testing something out and force set the bit-depth and sample rate in windows to 24/192. Then I noticed the issue with USB too. Essentially what I'm seeing is that when there is no sound being sent to the Directstream, the bit depth indicator on the screen drops to 16, but as soon as there's audio in a track or audio in a video I'm watching the bit-depth indicator pops back up to 24. The sample rate stays no matter how I have that set and doesn't fluctuate. I have an I²S source here too that I'll try out, but I'm going to assume the issue is there too.
Seegs108 said
The problem is not in the bridge code. I'm seeing the same issue via USB too. I was testing something out and force set the bit-depth and sample rate in windows to 24/192. Then I noticed the issue with USB too. Essentially what I'm seeing is that when there is no sound being sent the DS, the bit depth indicator on the screen drops to 16, but as soon as there's audio in a track or audio in a video I'm watching the bit-depth indicator pops back up to 24. The sample rate stays no matter how I have that set and doesn't fluctuate. I have an I²S source here too that I'll try out, but I'm going to assume the issue is there too.
Nope, that's not a bug it's by design. The DS measures what it gets - if the bottom eight bits are all zeros for a period of time then it displays 16 bits. If when a device pauses it sends all zeros then the display will say 16 bits - which is what is being sent. There's no way for the DS to know why you are sending only 16 bits... The metadata over S/PDIF, TOSLink, AES/EBU is notoriously unreliable and in some circumstances almost always lies about the sample rate. There isn't any metadata in I2S which is how the HDMI ports, USB and bridge talk to the FPGA.
Many sources display 16 bits for CD’s even when they are doing DSP and/or adjusting the volume. Isn’t it more useful for the DS to display 16 bits when only 16 bits are being used and 24 bits when 24 bits are being used?
FWIW it also displays 18 and 20 when that’s what it’s getting too.
Well don’t I feel dumb now. I wasn’t specifically looking to see if this issue affected the other inputs, but I went to adjust the volume via the touch screen and saw the bit depth information change and assumed it was the same thing that the others were noticing. But I suspect it actually is the same thing and that your “by design” implementation tells us a lot about MQA.
I don’t know if everything in the MQA path is working as designed, but it seems possible that they are. I believe (but don’t know for sure) that MQA has validation tests that they do and that they’ve probably run them on Rune, etc. Paul can correct me, but I believe they also ran them on the previous versions of the Bridge code. Also, why would anyone really expect that there’s any fidelity at all in the bottom 8 bits of something that’s been unfolded back to 24/192k?
Either way I think people are going to be upset. This kind of reminds me of a similar issue back when blu-ray players and HD-DVD players were first released. Some of the early hardware players couldn’t bitstream the DTS-HDMA or Dolby TrueHD formats so they’d decode internally and send out the audio as PCM. But because people weren’t seeing the DTS or Dolby logo light up on their AV Receiver’s display it drove them nuts. I have a feeling that (given there’s not actually an issue) people are going to be upset when it says 16 instead of 24 even though they aren’t missing out on anything anyways. 24 bits is just more visually comforting than 16. It helps them validate and justify paying for MQA.
Noticed this immediately after the Bridge II firmware update but it’s now happened three times.
The artwork doesn’t display. Though this has been an intermittent issue the whole time I’ve had the Directstream.
The difference now is that once it stops displaying it stays that way or seems to, on the tracks after. Previously it skipped the occasional track and then the artwork showed up on the next one.
The other issue is that the progress bar (not sure what you call it - but the timer bar under Input & Rate that shows the progress of the track) seems to stop working.
That’s three times now I’ve noticed this and after power cycling the DS off and on again it immediately resolves for a while. But then I notice it again.
Is anyone else seeing this?
Any thoughts on how I can try to resolve this or is it a bug?
Paul McGowan said
Thanks. Makes perfect sense. Indeed, we too have to pay Roon every time a unit is sold. Just part of the fun of it all.
Hmm.
Not sure if you meant to say something else, but you might want to check in with your accounting and legal folks, Paul… Roon is paid no fees at all… Not per unit license fees, up front fees, or certification fees… by any partners for embedding the RAAT SDK in their devices.
Can you clarify this for everyone here so the internet does not spread any wrong information?
