Ever since the contemporaneous Redcloud and Bridge II v3.4.5 updates, TIDAL MQA streams that used to appear on the DS display as 24/192 are showing as 16/192 (example: Neil Young, Hitchhiker). By contrast, TIDAL MQA 24/88.2 and 24/96 streams still show as 24/88.2 and 24/96 (example: Gov’t Mule, Revolution Come…Revolution Go (Deluxe Edition)).
It could be my imagination, but TIDAL MQA streams that used to display as 24/192 and that now appear as 16/192 seem to have taken a sound quality hit (example, Grateful Dead, Cornell 5/8/77 (Live) used to sound punchy and dynamic but now seems comparatively flat and uninvolving). Is it possible that the MQA ‘unfold’ is no longer working correctly on these streams? And if so, is there a fix in the works?
I can confirm the same issue. When I play a 24/192k MQA track via Mconnect Control app, it displays 16/192k in Redcloud. When I first begin playback, it initially displays “24” bits but after a split second, it changes to “16” and remains there the rest of the time.
Not an issue for tracks below 192k. They are displaying correctly at 24 bits.
Also, I am getting the correct “MQA.” (with “.”) displaying at top when the 192k tracks incorrectly display “16” bits.
It’s not clear to me that anything is wrong - everything in the chain could be working as designed. Perhaps we’re learning more about MQA than we expected. PS Audio is looking into anything on the Bridge that might do this, but I suspect the 16 bits displayed is correct.
It’s not clear to me that anything is wrong - everything in the chain could be working as designed. Perhaps we’re learning more about MQA than we expected. PS Audio is looking into anything on the Bridge that might do this, but I suspect the 16 bits displayed is correct.
The reason I believe there is a problem is the discrepancy between the information displayed on the ConversDigital Control app and the DirectStream display.
For example, I am playing The Singles (remastered) album by The Doors through Tidal. This is an MQA album - 24bit, 192.0kHz, 1372kbps. On the Control app, this is precisely what is displayed. However, on the DSD display, it is reading 192k and 16bit.
I can’t say for sure it is NOT playing in 24bit, but there certainly seems to be an issue of some type. The app data and DSD data are not matching.
Padded bits are gonna piss off a lot of people hoping for 24/192. I’ve come to learn that it doesn’t really matter what the bit depth and sample rates are. I’ve heard plenty of unremarkable (supposed) 24/192 MQA stuff and some rather excellent 16/44.1.
In regard to my last post with the The Doors MQA album, I am almost certain the DSD read 24/192k with the prior Bridge II firmware and Huron.
Anyone with the 3.3.3 Bridge II firmware and Huron able to check? I certainly don’t want to verify by going backwards in the software. You would need to play it via Mconnect Control app to the Bridge II
I’m not a Bridge or MQA user so I could easily be mistaken, but I believe the Converse MQA code has passed MQA’s quality tests (certainly we waited quite a while for the previous version to get thru MQA’s processes) - maybe they don’t care about the low bits or perhaps different options chosen during MQA mastering end up with more or fewer low order bits.
All I know is that there isn’t a problem in the FPGA reporting the bits it gets and if there’s ever 24/192 from the bridge in a file that also displays 16/192 (which was the original reporting of this problem) then the 24 bit path thru the Converse / Bridge to the FPGA is fine and all that’s left is the output of the Converse module.
Still it makes perfect sense that everything is working as designed.
All of that is speculation. Paul said they’d get to the bottom of it. I hope the answer isn’t that Converse fixes it by adding a non-zero low bit to 24/192
There is no question in my mind that TIDAL MQA albums which used to display on the DS at 24/192 are showing as 16/192 after the Redcloud/Bridge II v3.4.5 updates. The Neil Young and Grateful Dead albums I mentioned in post #1, above, are just two examples. Here is a post of mine from July 2017 (i.e., the Huron / Bridge II v3.3.3 era) with a contemporaneous photo I took showing the first Doors album as 24/192 MQA.:
I am not home at the moment or I would try it myself. Jeff, if you are near your system, can you check this album and see if it now shows as 16/192? Thanks.
What I don’t understand about MQA is why they even chose to do unfolds/encode the extra information within the audio anyways? HiFi 2 channel audio is already such a niche hobby as it and with large capacity harddrives being so cheap as they are, why don’t they just sell “MQA” music unfolded in the proper bit depth and sample rate? I get that it saves space and makes streaming it more cost effective, but the type of people who care about getting it wouldn’t mind it as a downloadable format (or even pay a little more for streaming services who offered it as a streamed format). It just seems so odd to me and creates a lot of hassle. Though I suppose they only did it because they know they could licence the technology and make a boatload off of it. It’s just a shame that’s it’s a pain in the ass and more expensive for us end users to ultimately listen to.
Please… Let’s not make this a “hate on MQA” thread. The Op posted a clearly defined problem and that is what is being discussed here. If you have a problem with MQA as a business/technology, that is fine, but I do ask you take it elsewhere.
Bootzilla, I am glad you took a screen shot of that track. I went ahead and found that track on Tidal and played it via the Control app. From your screen shot, you can clearly see that the DSD/Bridge was identifying it properly. It is a 24/192k stream and when you posted the screenshot, running Huron and Bridge II v3.3.3, the DSD displayed it properly as 24bit. However, in my system running Redcloud and Bridge II firmware 3.4.5, it is incorrectly displaying it as “16 bit.”
So, I am inclined to think it is not a problem on the side of MQA/Tidal, but rather a glitch in the new Bridge firmware.
Those that think it’s a Bridge update issue, roll back the software. It’s easy. Ask PSA to send you a simple windows program that allows any network connected windows machine to load any firmware version you might have (ask for an older Bridge version when you ask for the program). Dennis sent me the program and an older update months ago. I recently rolled back to something like V2.9.4. I am also experiencing issues with the latest version.
I posted this in another forum branch previously but this one now appears to the focus of the Roon/MQA discussion.
I am experiencing the same symptoms described by other getting 192/16 incorrectly and 88/24 MQA looking fine.
The new data point is the MQA 352 comes up as 176.8/18. Try playing the Stories album by Jan Gunnar Hoff (a 2L recording). Via Tidal Roon says 44.1, 24bit 2ch MQA 352.8 – my DSD says 176.4/18. I understanding unfolding to 352.8 is beyond the spec of the Bridge II however the 18 bits obviously is showing some data in the lower 8.
I’m seeing my Aurender struggle streaming this today, which usually is not an issue. Maybe Tidal is running into issues on their side with updates, issues etc.
Normally with RedCloud, I have not noticed any issues
Daniel Rosenberg said
I am experiencing the same symptoms described by other getting 192/16 incorrectly and 88/24 MQA looking fine.
The new data point is the MQA 352 comes up as 176.8/18. Try playing the Stories album by Jan Gunnar Hoff (a 2L recording). Via Tidal Roon says 44.1, 24bit 2ch MQA 352.8 – my DSD says 176.4/18. I understanding unfolding to 352.8 is beyond the spec of the Bridge II however the 18 bits obviously is showing some data in the lower 8.
The point is not what the source file says on the cover or what the web site says about a recording, but both how the file was mastered for MQA AND what path / devices did the unfolding and how.
If the DS displays 176.4/18 then it’s getting 18 non-zero changing bits like it says. This is actually more evidence that the 192/16 that some are getting is correct. I don’t know why people are worried about the low bits in MQA - they don’t have low bits of the audio at any time, the low bits of the audio were mostly nuked (or dithered into the higher bits) before the folding process began and instead the low bits of each MQAified sample are used to reconstitute the (high bits of) new samples when unfolding to higher sample rates. That’s just how MQA works.
