Hi Ted, I was impressed by latest Redcloud OS, especially the much reduced noise between PCM/DSD.
However, I noticed one odd thing when I played the first track (SACD via DMP+DSDAC Redcloud, and DSF file via Jplay+DSDAC Redcloud) of the Eagles’ Hotel California. The intro drum part has a heavy clipping noise and it continuous when the peak reaches above +0. Strangely, when I revert the OS back to Huron, Torrey, the clipping disappears.
Have you noticed any clipping issues with DSD/SACDs with high peak recordings?
Thanks for your feedback.
Indeed there’s a bug which (statistically) causes an internal overflow with high enough instantaneous levels. Since DSD can get 4dB louder than PCM the bug pops up more often with DSD, but some PCM can cause it to. Turning the volume down a little will change the character of the problem and turning it down a little more will work around it. The exact levels depend on the specific recording. Until the next release you can either turn Redcloud down a little or go back to Huron. More details are on various Redcloud threads.
Ted, Thanks for your quick reply.
I can certainly live without Hotel California for awhile… Looking forward to the next update!
I turned down the volume to 20/100 and the problem was still there for MQA files
There is a problem with the latest bridge code, I don’t know the details but I don’t think it happened to non-dsd files. Check with PS Audio support to see if your case is known or perhaps if there’s something else going on.
You are right. after rolling back to Huron i found out that Bridge was still at 3.5.1 instead of 3.3.3, thanks!
let’s add MQA files to the label as well…
PS: FYI, The Hotel California SACD track No.1 distortion is gone when the volume is set at 94/100.
Paul, is there a plan to update the Red Cloud release to eliminate the the clicks with certain SACDs? If the software exists, let’s hear it!
Throw, those of us waiting the DMP software update and ‘skinny’ looking AN2 speakers, a bone, man!!!
I would have to ask Ted about that. Maybe he’s reading. We’d love to have another mountain top to climb this year if possible.
The status is that Ted has discovered a bug or some, which are easy to correct. Most beta testers thought however that the first implementation, which makes specific choices about its fpga implementation, did not sound as well as the original redcloud, although the clicks are gone. That is why it was not released. As i understand the proces, it should mean that ted makes a dozen or so different implementations. Paul and others should then do the elaborate listening tests. Doing that looks like more Pauls call than Teds. Paul, Ted, is this correct more or less?
Edit: you can also think that all those efforts in those listening tests are a wast of money, because the lowering of the volume is an easy temporary cure. So, we can be thankful that paul and the company are working hard to get new exciting speakers to us! And a next sw release could than have new ideas for real sq improvement. Hopefully it will be there some time. And Paul, good luck with the speakers, will be a hard time making the choice for new speakers or the pre-amp.
Hi. This is the first I’ve heard of an issue with the latest Bridge release. Since I upgraded to said release, I am curious to learn more in order to prevent potential clipping-related damage to my speakers. I tend to ‘crank’ my DS up so I will certainly ‘wade into’ the volume, but any additional info would be nice . . . plans to fix the problem . . . next expected update, etc. Thanks!!!
You can turn the volume down a little to see if you are experiencing the known problem is in the Redcloud FPGA code. The quality of the distortions changes different volume settings but goes away below 94 (or so.) If you are still hearing a problem after that it’s something else (perhaps the bridge code.)
I can’t speak to the character of the particular problem except if it’s the Redcloud FPGA code: The bug in Redcloud doesn’t AFAIK cause the kind of changes to the sound that would hurt any equipment. The material must be loud already to cause the problem and at worst there are very short (much shorter than a PCM sample) excursions to the wrong places (tho there may be a lot of them for a small fraction of a second.) Should anything more radical happen the FPGA will mute until the problem has passed.