Observations with MUSE and resampling to DSD: DSD256 bug?

dvdr · September 7, 2025, 10:28am

Hi

I’m experimenting with various DACs at the moment.

I made a strange observation: resampling to DSD256 produces a pretty amount of high frequecy noise from 1kHz upwards in certain situations. Not so upsampling to DSD64 and DSD128.
I know about noise-shaping and dithering, so I was pretty surprised by that behaviour. Maybe someone here can jump in with an explanation - or have I even discovered a bug?

I am using a RME ADI-2/4 Pro SE for this. It is able to natively play DSD up to DSD256 via DoP.
Its display is able to show a spectrum analyzer even when natively playing DSD to its analog outputs, due to an extra DAC-section, that handles display and monitoring (that’s why you see a PCM sampling frequency at the bottom right of the display - DSD is definitely processed natively in the audio section).

In Roon Rock, I chose MUSE to resample everything to DSD256, including resampling DSD-files. Setting “smooth, minimal phase”, “7th order (CLANS)”, and “SMD gain adjust -3dB”, “native DSD processing (aka NO prior PCM conversion before resampling)”.
But all these settings can be changed, and the high frequency noise issue still persists.

When playing DSD64 files, I noticed that very “noise behaviour” throughout all my files - so its not the recordings. The screenshots stem from “noise free” classical studio recordings, always the first few bars where the orchestra still is not playing (or only very very faintly)

THIS IS THE NOISE ISSUE: DSD64 file upsampled to DSD256 in MUSE

FOR COMPARISON: another DSD64 file upsampled to DSD256 in MUSE

FOR COMPARISON: same DSD64 file playing natively with no upsampling in MUSE (NOTE that is virtually NOISE FREE from 400 Hz upward)

FOR COMPARISON: normal 44.1/16 file upsampled to DSD256 in MUSE (you can see the solo oboe playing a single, soft note…)

NOW TO DIFFERENT UPSAMPLING RATES FOR THE ABOVE DSD64 FILE (applies to any of my DSD64 files):

DSD64 upsampled to DSD128 in MUSE (sorry, only caught it while the orchestra was playing - but you can spot the difference: no high frequency issue)

DSD64 file upsampled - or better REsampled - to DSD64 in MUSE (so NO ISSUE stemming from the DSD file itself, definitively noise free)

Bottom line - as far as I understand the issue:

It seems to me, that upsamling a DSD64 file to DSD256 in MUSE produces a huge amount of noise in the audible range from 400hz/1kHz upwards - at least, that’s what I see in my spectrum analyzer. Looking at the various scenarios I tested, this seems NOT to be a noise shaping or dithering issue nor an issue with the RME and/or its spectrum analyzer. It also is definitely not file-related, since all the DSD64-files I tested can be played natively or with resampling to DSD128 and DSD64 with no noise issue.

Also, I tested (not shown here) a recording from the “2L test bench”, that is provided in DSD64, DSD128 and DSD256. I went through all possible combinations in MUSE.
No noise issue, when played natively or up-/re-/downsampled to DSD64, DSD128 or DSD256 - with the only exception, that DSD64 to DSD256 produced the noise issue.

It seems to be the combination DSD64 to DSD256, that produces the noise issue.

Since my spectrum analyzer only displays max. 20kHz, I cannot tell, whether in that scenario the HF-noise above 20kHz is even higher. Might put some stress on the the amp and the tweeters, especially at louder levels…

P.S.: it would be interesting, if someone using HQPlayer could try to replicate that - that way, we could see, whether this is an issue, that is inherent in the DSD64 to DSD256 conversion or whether this is caused by MUSE’s own resampling algorithms.

Marian · September 7, 2025, 9:32pm

This can’t be inherent to any kind of conversion. It seems MUSE has a bug that lets quantization noise - either from the original DSD or from its own modulator - seep into audible range.

Not sure if you already did it, but I would try using a sharp filter instead, and if that doesn’t solve it, try reducing the gain to -6 or even -9 dB. Also, please post the signal path.

dvdr · September 8, 2025, 12:42am

strong text

Hi Marian
Thanks for replying. After all the different test I made, I am sure to be able to say the following (and will provide some additional interesting findings, that might help to get the issue isolated):

The quantization noise does not stem from the DSD. I tried various DSF files (DSD64). They all had the same issue, but only with resampling to DSD256.
If the noise stemmed from the DSF file, it would have shown as well - and even more prominent, I guess - when resampling to DSD128 or DSD64. But those conversions, as you could see in my above post - were noise-free.
I did experiment with all the 4 filters available in MUSE: no changes whatsoever with the DSD64 to DSD256 resampling.
My gain already was at -3, but I tried -6 (maximum offered in MUSE): no changes.

So, here are some screenshots from the DSD64->DSD256 conversion tests I just conducted, again taking the start of a orchestra piece (studio recording), where the orchestra is quiet.

Gain reduction in the SAMPLE RATE CONVERSION options: -3dB + Filter PRECISE, LINEAR PHASE (steepest filter)

Gain reduction in the SAMPLE RATE CONVERSION options: -6dB + Filter PRECISE, LINEAR PHASE (steepest filter). Noise lowers for additonal 3dB

Gain reduction in the SAMPLE RATE CONVERSION options: -6dB + Filter PRECISE, LINEAR PHASE (steepest filter) PLUS HEADROOM MANAGEMENT with additional gain reduction of -3dB. Noise lowers another additonal 3dB

You see: Noise is still very prominent in the audible range, just a tad lower.

Now something really interesting happens:
I leave headroom management active at -3dB AND I leave sample rate conversion active, but set the custom option for DSD64 to default - meaning, that MUSE should not resample DSD64, but just pass it through unaltered. That’s when headroom manegement status seems to play a role in the outcome

Compare DSD64 set to “default” (aka pass through) with headroom management NOT active

… to DSD64 set to “default” (aka pass through") with headroom management ACTIVE

The noise is back! But, wait - why all of a sudden 705.6 kHz instead of 176.4 (symbolizing DSD256 instead of DSD64)???

Look at the path!!!

Despite “pass through” for DSD64 AND native DSD processing ACTIVE in SRC options, there is a PCM conversion taking place: sample rate to 352.8kHz, then headroom adjustment, then another sample rate conversion to 11.290MHz and then the DSD256 conversion. Plus: the noise is back!

Why that? There is NO NEED whatsover for any of that conversion, since I opted for native DSD processing. Upon further inverstigation, I found the culprit: it’s the switch for 352.8, that is causing it. When resampling options for PCM 352.8 are set to either DSD128 or DSD256, it will cause MUSE to do a complete DSD → PCM → headroom adjustment → PCM SRC → Sigma Delta Modulator roundtrip to (ALWAYS!!!) DSD256!

If I disable this switch (ONLY the 352.8 switch is relevant) or set it to DSD64 or any PCM frequency value, the “roundtrip” will not happen. All calculations are done inside the DSD realm and have no PCM processing involved - as you can see here:

So, bottom line: problems are occuring, when

DSD64 is converted to DSD256
conversion option for 352.8 kHz is set to DSD128 or DSD256
headroom management might play into it
you are not using the custom MUSE settings, but go for the overall “DSD256” resampling option.
Interestingly enough, activating the overall DSD256 option produces that noise problem - despite the suprising fact, that in this case, the signal path stays in native DSD processing

Marian · September 8, 2025, 1:29am

In DSD64, the quantization noise starts at lower frequencies and rises quicker than in DSD128, since you have only half the bandwidth to distribute it. Also, if it wasn’t DSD, you’d see the same thing when playing PCM, right?

That’s not what’s happening. DSD is one bit, and you can’t apply any DSP to that. Internally, Roon converts it to 64bit floating point (which is not shown in the signal path), applies DSP, then modulates back to 1 bit. That’s why you have the sigma-delta modulator in the path. Whether you want to call that 64-bit samples “PCM” or something else is just semantics.
Anyway, if the last signal path produces noise and the one before doesn’t, it could be from the up-sampling to 11.29 MHz.

dvdr · September 8, 2025, 2:21am

Marian - I know about quantization noise, dithering and all the shebang
But you are forgetting one vital thing in your argument:

When playing back my DSD64 files natively via Roon to my RME, there is no quantization noise in the output visible on my spectrum analyzer (lowest level visible is -60dB).
On Archimago's Musings: Notes on DAC DSD (1-bit PDM) measurements going forward... they show the quantization noise for DSD64 measurements of a similar RME DAC to mine:

We’re talking -140dB noise in the audible spectrum up to about 22kHz and above that, rising to about -80dB around the region of 80kHz. Perfectly clear, that on my small spectrum screen that is not shown. So native DSD playback is fine.
And it’s also fine, when I resample DSD64 to DSD128. Let’s set aside for the moment, HOW MUSE is doing that. Important fact is, that I don’t see the noise issue there, as well.

But resampling DSD64 to DSD256 produces a signal, that is a.) largely in the audible spectrum and b.) has a signal level up to -30dB. That is no quantization or dithering noise, that is something completely different.
That noise and these measurements for sure have nothing to do with a faulty, noisy DSD64 file per se. The proof for that is in the pudding - aka the graphs. You would see the noise of a faulty file in native playback.
I’ve never seen quantization / dithering noise with such a high level plus sitting so largely in the audible range. That is something, MUSE introduces during its resampling of DSD64 to DSD256. Again, if the came from the DSD64 file: why is the noise not present, when resampling to DSD128?

Marian · September 8, 2025, 3:41am

That’s obviously because that noise - in the case of unprocessed DSD64 - is outside of the audible band, which is what RME is showing.

I’m not saying it actually is quantization noise (i.e. produced by Roon’s delta-sigma modulator); I’m just saying it may have something to do with the quantization noise already present in the DSD64 signal that is up-sampled. The shape is suspicious; it steadily rises just like the quantization noise visible in the tails of the graphs you show. It is in theory possible for a faulty up-sampling filter to alias high-frequency content back into the audible band.

Maybe it has to do with up-samplig specifically from 2.8 to 11.3 MHz, who knows? We can speculate all we want. It would be good if you could pass a 2.8 MHz PCM signal that is guaranteed not to have any ultrasonic content and see what you get, but that’s not possible with Roon. You could try adding a low-pass PEQ with a 10-15 kHz or so cutoff and see what you get.

WiWavelength · September 8, 2025, 1:20pm

Relying on the RME’s coarse RTA is not a wise idea in this case. To generate the display, it is first decimating and sample rate converting the high rate signal — possibly in a very quick and rudimentary way that is aliasing ultrasonic noise into the RTA. You really should do a high quality ADC capture, followed by a high quality FFT just like the Archimago graphs that you have posted.

And you keep emphasizing that this is high level noise in the audible range. Well, is it audible? Have you actually listened to it and heard it? Because broadband noise around -40 dBFS you should be able to hear.

AJ

dvdr · September 8, 2025, 2:05pm

Agreed - there’s a German saying “Wer misst, misst Mist”, meaning “who is measuring something, will most probably measure wrongly and get crappy results”

Since I don’t have access to professional measuring equipment, I’m stuck - all I have, are the observations I made, which hinted to some possible problems in the implementation of resampling algorithms in certain cases. No explanation, yet, just observing and trying to provide info about various scenarios for the pros in this community to identify or rule out a possible bug - and maybe recreate the issue and follow it up with more professional measuring equipment.

To answer your question: yes, I can hear some noise, but not at a level measurements might suggest. Still, with the overall observations of all variables and their output, might it not be worth further investigation?

Here’s a last test I want to suggest looking at. I got hold of two testfiles. One is a DSD64 file with no inherent quantization noise (“silence.dsf”), one holds typical quantization noise. I tested them with various resampling scenarios. Interestingly enough, RME’s spectrum analyzer seemd to properly display noise or no noise at DSD256 (IF I interpret my results properly, you’ll be the judge of that - I may still draw the wrong conclusions)

Do you think, that in this case, the RME spectrum analyzer could be at fault or play a role here?

Here’s the test:

Even if that built in spectrum analyzer of my RME is limited to 20kHz, a below master VU-meter seems to be showing the summed up levels of frequencies even above 20kHz. Its range goes down to values of around -120dB, then it indicates “UFL”. This helped me to identify the presence of any noise above 20kHz not shown in the spectrum analyzer.

MUSE completely off, no resampling, no headroom management:

Silence dsf:

noise below measuring limits, as expected, both @VU-Meter and spectrum analyzer

Silence with Quantization Noise dsf:

noise of around -75dB shown in the VU-meter, quantization noise showing as expected
no noise in the audible range visible in the spectrum analyzer (caveat; above its -60dB limit!)

MUSE resampling to DSD256, no headroom management

Silence dsf:

-80db @VU-meter with switch “Native DSD processing” active
-75dB @VU-meter with switch “Native DSD processing” switched off.
No visible noise in spectrum analyzer for both settings

Silence with Quantization Noise dsf

noise of around -50dB shown in the VU-meter with switch “Native DSD processing” switched off.
No noise visible in the spectrum analyzer in the audible range (above its -60dB limit) with switch “Native DSD processing” switched off.
noise of around -11dB shown in the VU-meter with switch “Native DSD processing” switched on.
Noise in the spectrum analyzer starting at -60dB at 40Hz (!!!), raising constantly to -25dB at 20kHz with switch “Native DSD processing” switched on.

So, when MUSE clearly indicates the involvement of PCM processing in the chain, quantization noise (caveat: as far as I can see it on my RME!!!) is kept low and out of the audible spectrum. The moment their “native DSD processing” algorithm comes in, noise SEEMS to become a huge problem, when resampling to DSD256. This might be worth being followed up with professional gear.

MUSE resampling to DSD128, no headroom management

Silence dsf:

-75dB @VU-meter, NO influence of the switch “Native DSD processing” being switched on or off.
No visible noise in audible spectrum above -60dB in spectrum analyzer for both switch settings

Silence with Quantization Noise dsf

noise of around -66dB shown in the VU-meter with switch “Native DSD processing” switched off.
No noise visible in the spectrum analyzer in the audible range (above its -60dB limit) with switch “Native DSD processing” switched off.
noise of around -48dB shown in the VU-meter with switch “Native DSD processing” switched on.
No visible noise in the spectrum analyzer above its -60dB limit with switch “Native DSD processing” switched on.

Again, the algorithm of “native DSD processing” seems to have an influence, but this time not (so much) at the audible spectrum (at least not above the -60dB limit of my spectrum analyzer)

Finally, I did a quick cross check with SDM gain adjustment at -6dB PLUS headroom management active and adjustment set to -6dB, when resampling to DSD256. Noise problem persistst. Noise in the RME display show as overall lower, as expected, but frequency range of the noise stays the same for the audible spectrum.

Marin_Weigel · September 8, 2025, 5:02pm

If you can’t clearly hear a difference between this scenario …

… and that scenario …

… you better not trust in the information and just turn off the display.

Maybe raise your issue with RME to have them look into how they derive their signal display with your settings.

dvdr · September 8, 2025, 5:49pm

Marin - I really appreciate the help and the comments of you and the community. My whole question was not about what I could hear or not - I should have made that perfectly clear from the start. My bad! Of course, I would hear noise in the displayed range. I did not, only a faint difference of a bit more noise. But could I hear a problematic louder noise of above, let’s say, 16kHz?

But I’d like you to just take a different perspective for a moment, please. Maybe we can find some common ground.

If you come across a display like that, of course you would ask yourself “what’s the reson, that this only occurs at a certain scenario?” and start digging.

I completely understand, that RME’s spectrum analyzer could wrongly interact with some low level high frequency signal and create a display, that does not reflect reality. Cool, we have a solution!

Or it could be something, where right outside the range of the display and our audible range, some frequencies are produced by MUSE, that have a pretty high level. Let’s just for the sake of the argument say for a moment: MUSE produces noise from 25kHz up at levels of -11dB.
RME will somehow grab it, wrongly create some “mirror frequencies” in their display processor and display them. Wrong display output, but caused by something, that might turn out to be problematic.
I could not hear that, but an amplifier or tweeter could easily get into trouble: in that theoretical example, that signal would be about 20dB above my listening volume of a moderately played classical piece. Since I have no professional measuring equipment, I could not verify that.

So: whatever the reason is, but could the very display then give us a hint, that something is going on, especially if this is limited to only one single scenario - the DSD256 conversion? Shouldn’t I ask the community to take a look into that?

Again, please understand me right: I don’t claim that I KNOW, that there’s a bug or severe problem. I’m just seeing something uniquely limited to ONE scenario and trying to understand the implications.

That’s all I wanted to ask.

MarcMarc · September 8, 2025, 7:25pm

Someone correct me if I’m wrong but the ESS chip in there won’t let you bypass its SDM. You are adding headroom and that causes a pcm conversation (even if you call it floating point).
So what’s the reason behind DSD256 upsampling if you are messing with the DSD 1-Bit file multiple times ?

And you aren’t even using HQPlayer.

Rugby · September 8, 2025, 8:31pm

Depends on the version, I think. My ADI PRO FS BE uses the AKM chip ADI-2-Pro FS R BE - RME Audio Interfaces | Format Converters | Preamps | Network Audio & MADI Solutions. Which can be set to Direct DSD mode. I’m using it that way with HQP as I type this.

ESS chips cannot play dsd direct, they convert the DSD signal to a multi-bit PCM signal before analog output. If you want direct DSD to analog conversion you need a DAC which does this.

dvdr · September 8, 2025, 8:32pm

Hi MarcMarc - at the outset, I just wanted to listen to DSD and have a good, stable AD/DA, that could digitize my reel to reel live recordings and some valuable records to DSD rather than PCM. Since I know and trust RME from recording studios, my choice was their latest model (targeting mastering studios and expert home users alike).
All the “messing with the DSD 1-Bit file” just were experiments I did in the search of an explanation, why upsampling to DSD256 seemed to produce a noise issue in certain configurations and at what stage that happened. Hence the ton of variations.

As to why I touched upsampling to DSD256 in the first place was just the attempt to see (and HEAR, of course), whether sound quality of native playback of PCM and DSD would benefit from upsampling. You sure know about the discussion, whether upsampling is beneficial by hitting a “sweet spot” at processors and filters, so to say…
So I tested that in my listening room, where I stumbled over the above described “noise”-issue (that may or may not turn out to be an issue at all).

As for the ESS-chip: as far as I read the various technical sources and the manual, PCM is fully processed as PCM, which is the default mode of the unit. If DSD is present on any input as DoP, it will switch to DSD processing and therefore all processing that would require a conversion to PCM (filters, equalization etc.) is completely bypassed. Only volume control of the output is done - as ESS engineers claim - in the DSD-realm with a special technique, that sets in right at the analog conversion level.
So, yes, if you refer to something like “DSD direct” from AKM chips: ESS is not doing that, but ESS engineers claim, they still stay fully DSD throughout the unit.
But there’s loads of discussions about that claim, I would not want to conceal that.

As for HQPlayer - that is the next thing I thought of looking into. But that requires an extremely elaborate and powerful computer, as far as I understood. So that might have to wait a while.

dvdr · September 8, 2025, 8:41pm

There is an interview with a leading ESS engineer, who says the following - is that, what you mean by multi-bit-PCM signal or do I understand the engineer right, that he describes a different, NON-PCM process here?

MW: How do you handle volume control in that final output stage? Do you convert to analog and then turn it up and down.
JS: We actually don’t. We do process that at the high sample rate and we have multiple 1-bit converters that are available to us. So the increase in word length that we get as a function of that volume control makes use of the redundant 1-bit converters that we have running in parallel.
MW: I see.
JS: So we’re not converting it…in a way you could look at that as if it’s PCM because there’s multiple 1-bit converters summed together in the analog domain. But that’s what you have to do to get volume control to work. The good thing is we don’t take it from 1-bit to multi-bit and back to 1-bit before we convert it to analog.
MW: Yep, as you were saying before.
JS: Instead of sending identical DSD signals to sixteen balanced 1-bit converters that are wired in parallel, we start sending different DSD signals to reduce the signal amplitude. All summing occurs in the analog domain. It is very cool!

dvdr · September 8, 2025, 8:54pm

P.S.: My playback chain is Roon Rock → LAN → SoTM SMS200-Ultra NEO → USB → RME.
Since the SMS200 as a Roon network bridge has a HQ-Player NAA “app” built into its “Eunhasu” firmware, I’d be happy to give it a try, if it can be done in a way, where I don’t have to do huge investments. I could provide a MacBook Pro M1 Max (64GB Ram) for HQPlayer. If it’s not underpowered, that might help for a jump-start-trial…

Burkhardt_Petermann · September 9, 2025, 4:05am

At first I would test the RME with a native DSD256 file and then you see, if Muse is the cause or not.