Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JJ77]

Followed all instructions and conversion completed. The JMC instructions say the output should be (Once you have PCM),  64bit @ 352.8 kHz for DSD.

 The audio properties on the converted files show 24bit???  The file seems to sound ok? The converted file also shows 152,21 MB 72% compression, Original size 537MB, Sample rate 352.8 KHz, Bit Rate 16,934 (DVD), Encoder ibFlac 1.2.1 20070917, Audio Quality Perfect (lossless).

Is this correct or am I doing something wrong to get 24bit instead of 64 bit?  Thanks for any help!

[connersw]

Sounds right.  Do you have a link for the instructions you followed?

By default, MC converts DSD to PCM 64bit @ 352.8 kHz for playback.  This is basically "on the fly" conversion for real time playback.

If you are converting files for archiving, the FLAC codec only supports up to 32bits per sample; however, I have never seen that used.  Typically it is 16 or 24bit since that is what hardware supports. I do not know how to change the bit depth for the FLAC encoder in MC; in Audacity I believe there is a drop down, but I have not used it in a very long time.

[JJ77]

http://wiki.jriver.com/index.php/DSD_Format      Really appreciate your reply 

[connersw]

Yeah, the 64bit @ 352.8 kHz referred to in the wiki is for real time playback. 

May I ask why you are converting?  Just for compression/storage or for playback on other devices?  If it's the latter, you may want to look at step #6 and use 192kHz or even 96kHz for the Sample Rate.   Very few players will handle such a high Sample Rate. 

[JJ77]

Thanks again for the reply. I did go in and set the KHz that high as thought I was supposed to set it to come out that high. I misunderstood the real time "On the fly. I will go back and reconvert to 192Khz.

  I wanted to convert so my set-up ---Vortexbox Nas to Logitech Squeezebox Touch (WiFi) to Nu Force HD DAC (S/PDIF) would play DSD files. It is playing them with the 352.8 KHz. The files play and do sound better than the same (non DSD files) files I downloaded at 96 or 192 for a test. I noticed I have to turn the volume higher on the DSD converted files to get the same output level???  But you can hear the difference even over the 192KHz files.  Eventually I hope to get a DSD DAC. It said in the instructions that I should get the same result as DSD to DSD, but I have no way on knowing what is really the end result.

[connersw]

I do not own a Squeezebox so I am not intimately familiar with all of its capabilities.  However, I would think that you could save yourself the conversion and hard drive space by having MC send the original file and do any required conversion on the fly.  Perhaps AndrewFG could chime in since he would know way more about this than me. 

I know MC does apply a low pass filter to DSD files so that may explain the volume difference.  You may want to look at MC's audio analysis and volume leveling tools to adjust:  http://yabb.jriver.com/interact/index.php?topic=82025.0

PS: I found where you can set the Bit Depth for the FLAC encoder in MC.  After you select Convert Format, click on Options in the Action Window -> Audio -> Bitdepth (at the bottom).  It does max out at 24bit though, so your original file is correct.  Anything higher, and the encoder won't produce a file.   

[JJ77]

I really appreciate your advice. I hope sometime to gain enough knowledge about the technical aspects so I know what I am doing or trying to do. In the mean time its people like you that make it possible to move ahead. Thanks again

[john greenwood]

I just converted a number of DSD files (originating from ripped SACDs) to 88.2/24 FLAC (for use with my Squeezeboxes) and I also found the resulting file was 8-10 db lower in volume than the original recording.  I confirmed that I had not accidently checked normalize to 95% before encoding.  Any other explanation?

[AndrewFG]

I do not own a Squeezebox so I am not intimately familiar with all of its capabilities.  However, I would think that you could save yourself the conversion and hard drive space by having MC send the original file and do any required conversion on the fly.  Perhaps AndrewFG could chime in since he would know way more about this than me.

Squeezeboxes cannot play native DSD. If playing a file natively to a Squeezebox, the best format is probably AIF (because it is essentially the Squeezebox internal format and no additional transcoding or bit shifting is needed). But if playing to a Squeezebox via UPnP / DLNA, either via the Logitech plug-in or via Whitebear, then Flac is probably just as good, (LMS has to do a bit of transcoding, but the transfer requires less communications bandwidth).

Followed all instructions and conversion completed. The JMC instructions say the output should be (Once you have PCM),  64bit @ 352.8 kHz for DSD.

The audio properties on the converted files show 24bit???  The file seems to sound ok? The converted file also shows 152,21 MB 72% compression, Original size 537MB, Sample rate 352.8 KHz, Bit Rate 16,934 (DVD), Encoder ibFlac 1.2.1 20070917, Audio Quality Perfect (lossless).

Is this correct or am I doing something wrong to get 24bit instead of 64 bit?  Thanks for any help!

I don't think you are doing anything wrong at all.

But I do agree with you that the Wiki's statement about "64bit" is at least confusing if not totally wrong. The statement really means that when MC is converting from DSD to PCM it does its internal processing using the CPU's 64bit integer register operations, to ensure that any losses due to integer rounding are shifted down to a level many orders of magnitude below the level of human perception. Nevertheless once MC has done all of its conversion filtering and processing, it must then convert those internal 64bit integer values to something that can either 1) be saved in an audio file (e.g. Flac), or 2) streamed directly to a DAC. And in both cases 1) & 2) the highest possible resolution with today's technology is "only" 24bit.

In other words, all internal processing is done at 64bit inside the CPU, and only the last step converts from 64bit to 24bit. Of course, there might be an integer rounding error at this last step, but a) it is better than having integer rounding errors at all steps in the processing, and b) even a rounding error at 24bits is ~12dB below the threshold of human hearing.

I just converted a number of DSD files (originating from ripped SACDs) to 88.2/24 FLAC (for use with my Squeezeboxes) and I also found the resulting file was 8-10 db lower in volume than the original recording.  I confirmed that I had not accidently checked normalize to 95% before encoding.  Any other explanation?

Based on the above, the following is just my own theory...

Background: If the final output is 24bit, then when you create your CPU internal 64bit integer register value, you have 40bits of free room to play with. When doing integer arithmetic in a CPU you have to avoid a) low bit rounding errors, and b) high bit integer overflows. For the best accuracy concerning low bit rounding you would allocate all the 40 "spare" bits on the low order end of the register. But to avoid high bit integer overflows, you must allocate a few of the "spare" bits as headroom on the high order end of the register.

So my theory is that when MC does the initial conversion into internal 64bit register values, it applies 2..3 bits of (extra) headroom to avoid integer overruns, but that when it converts the internal 64bit register value for output to a 24bit file or DAC, it is perhaps not removing these -- no longer needed -- (extra) headroom bits. This would result in a volume reduction approximately of the order being observed. EDIT: and this would also mean that the DAC is getting only a 21..22 bit resolution signal instead of the full 24bits that it should be getting; thus nullifying any advantages that you may have gained by avoiding integer rounding errors in the first place...

[john greenwood]

. . .

Based on the above, the following is just my own theory...

Background: If the final output is 24bit, then when you create your CPU internal 64bit integer register value, you have 40bits of free room to play with. When doing integer arithmetic in a CPU you have to avoid a) low bit rounding errors, and b) high bit integer overflows. For the best accuracy concerning low bit rounding you would allocate all the 40 "spare" bits on the low order end of the register. But to avoid high bit integer overflows, you must allocate a few of the "spare" bits as headroom on the high order end of the register.

So my theory is that when MC does the initial conversion into internal 64bit register values, it applies 2..3 bits of (extra) headroom to avoid integer overruns, but that when it converts the internal 64bit register value for output to a 24bit file or DAC, it is perhaps not removing these -- no longer needed -- (extra) headroom bits. This would result in a volume reduction approximately of the order being observed. EDIT: and this would also mean that the DAC is getting only a 21..22 bit resolution signal instead of the full 24bits that it should be getting; thus nullifying any advantages that you may have gained by avoiding integer rounding errors in the first place...

Wow - I hope that's not the case as it would suggest that (to my non-technical mind) that all DSD to PCM conversions by JRiver reduce resolution and decrease volume.  I find it hard to believe this has not been more extensively commented upon.  As I did not get the sense that everyone using JRiver's conversion feature experienced these volume loss, I assumed it was a setting I had overlooked.

[Hendrik]

So my theory is that when MC does the initial conversion into internal 64bit register values, it applies 2..3 bits of (extra) headroom to avoid integer overruns

While I don't have any grand experience with DSD conversions, I can tell you that this theory is wrong.
The internal format is 64-bit floating point (or "double" rather), it does not suffer from integer overruns and therefor does not need to reserve headroom. Floating point can easily exceed "100%" in intermediate steps, which is why its preferred for processing.

How are you comparing playback of the two? With a DSD DAC? Maybe your DAC just plays DSD content louder for some reason?

[john greenwood]

While I don't have any grand experience with DSD conversions, I can tell you that this theory is wrong.
The internal format is 64-bit floating point (or "double" rather), it does not suffer from integer overruns and therefor does not need to reserve headroom. Floating point can easily exceed "100%" in intermediate steps, which is why its preferred for processing.

How are you comparing playback of the two? With a DSD DAC? Maybe your DAC just plays DSD content louder for some reason?

I am comparing ripped versions of the redbook layer and SACD layer (ripped with a PS3) from the same disc.  My Squeezebox does not have this problem with other FLAC files (e.g. downloaded from HDTracks).

Also - see post 5 here.  I am not alone.

[AndrewFG]

...  I can tell you that this theory is wrong.

Ok. Sorry...

[john greenwood]

Someone in the Steve Hoffman forum had a similar experience.  He also tried it in dbPowerAmp (using its beta dsd convertor) without the same issue.  His conclusion - bug.

[Hendrik]

If you analyzed the DSD file in Media Center, what do the fields "Volume Level (R128)" and "Peak Level (R128)" (the first value is enough) say?
Can you import one of the FLAC files you converted, analyze it, and compare the information? Ideally it should be the same. It'll help us to pinpoint where the problem is.

If you play the DSD file in Media Center, it has the proper volume?

[john greenwood]

If you analyzed the DSD file in Media Center, what do the fields "Volume Level (R128)" and "Peak Level (R128)" (the first value is enough) say?
Can you import one of the FLAC files you converted, analyze it, and compare the information? Ideally it should be the same. It'll help us to pinpoint where the problem is.

I will try to do that tomorrow night.

Bear in mind that I am still a newb with JRiver.  Do I need to do something specific to analyze a file or just check the appropriate fields?

[Hendrik]

If the files are already in your library, you can just select them and right click -> Library Tools -> Analyze  Audio

[Hendrik]

Oh and another question, in options of the converter (Options link in the Convert Format action window), do you have "Apply DSP" checked, and if yes, in the DSP settings, is Volume Leveling active?
Volume Leveling *will* lower the volume on most audio, as it targets a average volume of -23 LU, while most audio files are in a range of -15 to -5 LU.

[john greenwood]

Oh and another question, in options of the converter (Options link in the Convert Format action window), do you have "Apply DSP" checked, and if yes, in the DSP settings, is Volume Leveling active?
Volume Leveling *will* lower the volume on most audio, as it targets a average volume of -23 LU, while most audio files are in a range of -15 to -5 LU.

Certainly possible.  I will check that as well.

[JJ77]

Oh and another question, in options of the converter (Options link in the Convert Format action window), do you have "Apply DSP" checked, and if yes, in the DSP settings, is Volume Leveling active?
Volume Leveling *will* lower the volume on most audio, as it targets a average volume of -23 LU, while most audio files are in a range of -15 to -5 LU.

I checked my settings too and volume leveling was not checked. If I play the converted file back through the JR Media Player to my DAC it appears the sound level is the same as if channeled from the squeezebox setup. The sound levels are lower than if the unconverted DSD file is played direct through JR Media Player? I have not got my DSD DAC operational with my setup yet. When I do I will compare that. Currently playing the converted DSD files through either the laptop using JR MPlayer or the Squeezebox Touch (both players supplied through a Vortexbox NAS). The laptop does have a HiFace 2 USB converter with a coax cable to the audio authority digital switch with a coax to the DAC. The squeezebox Touch is wireless with a coax to the  digital switch and coax to the DAC  (DAC is Nuforce ICON-HDP).  It was also recommended that I use 176kHz instead of 192 kHz. for conversion. It did not seem to change the result however.

The audio analysis shows Peak level sample -3.3 dB;-3.3Left; -4.0 on the converted file. The original DSD file does not have the -4.0, but everything else is the same.

[john greenwood]

My analyze audio test shows little volume level difference between the DSF and the FLAC file, but a 6 LU difference on volume level replay gain between both of those and the ALAC ripped from the redbook layer.

I want to do some more testing, but not tonight.

Edit - I was surprised at this result as it would suggest that the problem lies in either ripping the SACD or extracting the DSD files from the ISO.  Despite having done a great deal of research, I had not heard mention of this.

One other thought occurs to me.  I know that when I play back a DSD file on my computer, JRiver is converting it to PCM on the fly. In addition I have not configured JRiver to stream DSD (or DoP) to an external DAC.   Is it possible that the audio analysis is on the converted file?  There is some logic to that as it is the PCM file that would be heard/streamed.

[Hendrik]

The analysis only works on PCM.
The question this at least solves is to clarify if the issue is in the encoding to FLAC, or the conversion from DSD to PCM.

Now the remaining question is if the DSD layer on the SACD is maybe just quieter, or if the conversion is the cause.
It might be intentional to solve other issues in the conversion, since DSD to PCM is a hairy topic, but I won't know before investigating further.

Since this never was a question before in several years of DSD support, I'm not convinced that there is an actual bug here. It might just be inherent to DSD to be quieter once converted to PCM.
foobar2000's SACD plugin has for example a setting to boost DSD by +6dB after the PCM conversion, maybe to offset such an inherent property of the DSD conversion?

In a perfect world your Squeezebox would support ReplayGain or R128 audio tags, and could produce a normalized volume for you no matter what the file volume was.
(Edit: A quick check suggests that Squeezebox should support ReplayGain.)

[JJ77]

The analysis only works on PCM.
The question this at least solves is to clarify if the issue is in the encoding to FLAC, or the conversion from DSD to PCM.

Now the remaining question is if the DSD layer on the SACD is maybe just quieter, or if the conversion is the cause.
It might be intentional to solve other issues in the conversion, since DSD to PCM is a hairy topic, but I won't know before investigating further.

Since this never was a question before in several years of DSD support, I'm not convinced that there is an actual bug here. It might just be inherent to DSD to be quieter once converted to PCM.
foobar2000's SACD plugin has for example a setting to boost DSD by +6dB after the PCM conversion, maybe to offset such an inherent property of the DSD conversion?

In a perfect world your Squeezebox would support ReplayGain or R128 audio tags, and could produce a normalized volume for you no matter what the file volume was.
(Edit: A quick check suggests that Squeezebox should support ReplayGain.)

Under audio settings on the squeezebox there is a volume adjustment that currently is set at "no adjustment". There is an option for smart gain. Possibly that would accomplish the replay gain? I will try to find more info on the squeezebox setup to see. I do have my output at fixed 100% volume.

[6233638]

If I recall correctly, the maximum permitted signal level for SACD is equal to about -6dB for PCM audio.
Most hardware players, and many software players will apply a +6dB boost to the output to compensate for this.
 
However, when this topic was brought up last, it was found that a number of SACD discs are not mastered correctly, and adding 6dB would drive them to clipping.
Since there are Volume Leveling and Peak Level Normalization tools in Media Center, it would be better to use those rather than blindly increasing the volume by 6dB and potentially clipping the audio.
 
 
Similarly, when using DSD Encoding, the volume level is reduced by 6dB because most DACs will boost the signal by 6dB and clip the signal.

[Hendrik]

Thanks, that seems to confirm the information I managed to dig up on the subject.
Quite a lot of the DSD tracks I analyzed even have a True Peak of over -6dB, closer to -5dB, so boosting by 6dB would be bad for those.

In my opinion, there is no bug with the volume of DSD conversions. MC just doesn't apply the 6dB boost that other converters seem to apply, because as 6233638 says, its rather risky to do so.

[6233638]

Quite a lot of the DSD tracks I analyzed even have a True Peak of over -6dB, closer to -5dB, so boosting by 6dB would be bad for those.

If you think that's bad, some discs have tracks with peaks above 0dB!
 
On the subject of DSD to PCM conversion though, I wonder if the filters used to convert to PCM should be modified.
I did have a post on this a while back, but I think it was in the beta forum.
 
There are a few issues with the current implementation:

1. The same filter is applied to both 1xDSD (64fs) and 2x DSD (128fs)
With 2xDSD files, the noise starts at twice the frequency that it does in 1xDSD, so the filter should be extended.
 
2. In my testing, the current filters do not seem to perform their intended function.
 

• The 24kHz filter is not strong enough to filter out all spurious tones in the ultrasonic range. I forget the specifics now, but I think it required a 72dB or 96dB filter for that, rather than 48dB/octave.
• The 30kHz filter allows for an extended frequency response, but is not strong enough to filter out all the ultrasonic noise above this. Changing it from a 24dB/octave filter for a 48dB one seemed to fix this.
• The 50kHz filter is not following the scarletbook spec, as I understand it. It should be a 30dB/octave butterworth filter rather than a 24dB/octave filter.

This PDF might be of interest: http://www.sonicstudio.com/pdf/dsd/SACD_SignalPropertiesV13.pdf
 
 
If I can find somewhere to host them, I can probably upload some sample tracks if you need them.
I am not the most knowledgeable about how these filters work. I'm just looking at a spectrum analysis of the tracks after conversion to PCM.

[JJ77]

The smart gain on Squeezebox seems to have solved my problem???  ie. I have more volume on my headphone adjustment with the DAC set at the same level output. No clipping so far. In any event, the JR Media Center seems to do a very good job converting the DSD file in a flac container. I have heard Shelby Lynne's Just a little lovin' on a DSD DAC (and soon hopefully on my own DSD DAC) and the sound reproduction is extremely close to the JR conversion.) When I can compare more closely on my own setup, I will know more, but the JR conversion seems to be  very acceptable alternative to the rather expensive DSD DAC.

[john greenwood]

Yes - now that I am reminded, I am pretty sure that the documentation for Ayre mentions the boost.

That solved the problem for me as well during experimentation.  I generally leave that off except in shuffle mode for fear (rational?) that it degrades the sound.

Simply cranking up the pre-amp works too.

[AndrewFG]

 I feel slightly vindicated here. Even though my theory about headroom was wrong, it turned out that the issue is indeed about headroom...

[john greenwood]

I'm actually rather pleased with this answer.  It means I don't have to re-tag, re-convert, re-extract and/or heaven forbid, re-rip my SACDs.  Just apply replay gain or crank up the volume.

[dean70]

If you think that's bad, some discs have tracks with peaks above 0dB!
 
On the subject of DSD to PCM conversion though, I wonder if the filters used to convert to PCM should be modified.
I did have a post on this a while back, but I think it was in the beta forum.
 
There are a few issues with the current implementation:

1. The same filter is applied to both 1xDSD (64fs) and 2x DSD (128fs)
With 2xDSD files, the noise starts at twice the frequency that it does in 1xDSD, so the filter should be extended.
 
2. In my testing, the current filters do not seem to perform their intended function.
 

• The 24kHz filter is not strong enough to filter out all spurious tones in the ultrasonic range. I forget the specifics now, but I think it required a 72dB or 96dB filter for that, rather than 48dB/octave.
• The 30kHz filter allows for an extended frequency response, but is not strong enough to filter out all the ultrasonic noise above this. Changing it from a 24dB/octave filter for a 48dB one seemed to fix this.
• The 50kHz filter is not following the scarletbook spec, as I understand it. It should be a 30dB/octave butterworth filter rather than a 24dB/octave filter.

This PDF might be of interest: http://www.sonicstudio.com/pdf/dsd/SACD_SignalPropertiesV13.pdf
 
 
If I can find somewhere to host them, I can probably upload some sample tracks if you need them.
I am not the most knowledgeable about how these filters work. I'm just looking at a spectrum analysis of the tracks after conversion to PCM.

+1 on the steeper filters. I currently stack a 30khz 24db/oct filter with a second one using the parametric eq to get the US noise down to a reasonable level.

[mwillems]

2. In my testing, the current filters do not seem to perform their intended function.
 

• The 24kHz filter is not strong enough to filter out all spurious tones in the ultrasonic range. I forget the specifics now, but I think it required a 72dB or 96dB filter for that, rather than 48dB/octave.
• The 30kHz filter allows for an extended frequency response, but is not strong enough to filter out all the ultrasonic noise above this. Changing it from a 24dB/octave filter for a 48dB one seemed to fix this.
• The 50kHz filter is not following the scarletbook spec, as I understand it. It should be a 30dB/octave butterworth filter rather than a 24dB/octave filter.

This PDF might be of interest: http://www.sonicstudio.com/pdf/dsd/SACD_SignalPropertiesV13.pdf
 

I remember the thread you're talking about, and I recall that the filters in general definitely needed to be steeper.  A 24dB low pass butteroworth at 30Khz is only 3dB down at 30KHz, and only 24 dB down at 60KHz.  My recollection is that these recordings tend to have significant amounts of ultrasonic noise in the 30 to 35 Khz range which would not be adequately attenuated by such a filter.  

That said, the 24KHz scenario should not need a steeper filter than the 30KHz scenario, it should probably be the opposite (30KHz should need a steeper filter than 24KHz).  Extremely steep filters (like a 96dB filter!) that close to the audio band can cause ringing and phase distortion which would possibly be audible in the audio band, and might not be an ideal default setting.  

Folks can always experiment and see, but I'd suggest starting with two stacked 12dB or 24dB filters to effectively get a 4th or 8th order linkwitz-riley; LRs are 6dB down at the setpoint frequency instead of 3dB (which is a big difference).  It effectively front loads the attenuation, so even with the same effective slope you're getting better attenuation sooner.  That is to say, a 4th order butterworth at 30KHz and two stacked 2nd order butterworths at 30Khz will both be 24dB down at 60Khz; however, the former will only be 3dB down at the 30KHz, whereas the latter will be 6dB down at 30KHz.

[6233638]

I remember the thread you're talking about, and I recall that the filters in general definitely needed to be steeper.  A 24dB low pass butteroworth at 30Khz is only 3dB down at 30KHz, and only 24 dB down at 60KHz.  My recollection is that these recordings tend to have significant amounts of ultrasonic noise in the 30 to 35 Khz range which would not be adequately attenuated by such a filter.  

That said, the 24KHz scenario should not need a steeper filter than the 30KHz scenario, it should probably be the opposite (30KHz should need a steeper filter than 24KHz).  Extremely steep filters (like a 96dB filter!) that close to the audio band can cause ringing and phase distortion which would possibly be audible in the audio band, and might not be an ideal default setting.  

Folks can always experiment and see, but I'd suggest starting with two stacked 12dB or 24dB filters to effectively get a 4th or 8th order linkwitz-riley; LRs are 6dB down at the setpoint frequency instead of 3dB (which is a big difference).  It effectively front loads the attenuation, so even with the same effective slope you're getting better attenuation sooner.  That is to say, a 4th order butterworth at 30KHz and two stacked 2nd order butterworths at 30Khz will both be 24dB down at 60Khz; however, the former will only be 3dB down at the 30KHz, whereas the latter will be 6dB down at 30KHz.

Well the way I saw it was this:
 

• Filter 1: The goal is to filter out all spurious tones in DSD material. This includes tones in the 30kHz range. 24kHz with a stronger filter seemed to be about right.
• Filter 2: Allow for the full frequency extension of DSD, spurious tones and all, while filtering out the ultrasonic noise. 30kHz at 48dB/octave seemed to be ideal for this.
• Filter 3: A weak filter which follows the scarletbook spec. This allows for the most frequency extension, but does not filter out 100% of the ultrasonic noise. As far as I know, this just needs to be changed from 24dB/octave to 30dB/octave - though stronger filters are permitted.

Here's an example of what I mean by ultrasonic noise, using the 50kHz filter.
 
You can see that there is a gap between the music (this was clearly an upsampled disc) and the ultrasonic noise above it, which starts about 30kHz.
I have other discs which don't even extend their frequencies that high, and make the separation even easier to see.
 
And this is what I mean by spurious tones:

• 50kHz filter
  
• 24kHz filter
  

 
You can see that the 24kHz filter is not strong enough to filter out these spurious tones.
Again, that was just the first example I found, some discs are even worse.
 
Note: these graphs only go down to -120dB (20-bit) rather than -144 dB. (24-bit)
I just used this tool because it was convenient, SoX will let you customize the range used.
 
 
As things currently are, only the first filter is really useful.
With these changes, both Filters 1 & 2 would be viable options.
Filter 3 would be available if someone wants to follow the spec. (though I wouldn't recommend it)
 
Edit: And here's an unfiltered 2xDSD (128Fs) file just to show that it's clean to about 60kHz

[Hendrik]

Sadly this was all Matt's playfield, and I honestly don't know enough about DSD audio math (yet) to try to hack around in the low-pass filters used.
If someone convinces me with proper documentation from some credible sources or something like that, or just explains it all really well, I could change the filters used, but otherwise I either have to learn a lot, or Matt will have something to look forward to when he comes back. Whichever comes first, although that is probably going to be Matt being back

[6233638]

No problem. I just assumed it was a "hidden" filter being applied in the PCM stage which might not be difficult to change.
It's not that the options we have now are terrible, and you can set up custom filters in the Parametric EQ anyway. (but they also get applied to PCM)

[Hendrik]

The filter is part of the DSD input plugin (immediately after the conversion to PCM). Its probably not hard to change (I haven't checked yet), but I want to be sure that I'm doing the right thing - and I just don't have the knowledge about DSD yet to decide that on my own.
We have finished butterworth lowpass filters for 6/12/24/36/48 dB/octave that just need applying, anything stronger (or in between) would need implementation first.