Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: DSD problems foobar2000 v2.24.2 (32-bit) (Read 4559 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: BUG foobar2000 v2.24.2 (32-bit)

Reply #25 –
@Porcus and @Case - what do you think:

My use-case is:
1. Multichannel SACD - I use sacd_input and choose PCM as output (via HDMI to AVR; wasapi exclusive) with 192/24 sampling (that is what my AVR can handle).  I use one of the filters available in sacd_input or one of those I found on S-Audio.Systems. So I convert on-the fly to 192 and filter resulting PCM. Is this correct and is this OK (optimal)? Beside "hacking" foobar by sacd_input - do you think that this component does it worse than FFMPEG would? My guess would be that the component even uses some parts of FFMPEG to do it (just my guess).
2. Stereo SACD - I use sacd_input and choose DSD (+fake PCM for visuals etc.) as output (via USB and via ASIO+DSD [that one because I want it to be Native and not DoP]). The DAC sees 2,8MHz and uses FIR no. 1 (which is 39kHz). According to what Case has written earlier there could be a problem that:
DAC converts DSD do PCM to apply FIR - which is generally similar operation to what FFMPEG would do but FFMPEG would be...what....more efficient, less error-prone, more precise....? Assuming that general DAC performance is more or less equal with DSD and PCM....do we really need full PC power to do those operations....wouldn't DAC (being a "machine" built solely to do D/A Conversion) have sufficient resources and power to do its job with proper precision and outcome?

Re: BUG foobar2000 v2.24.2 (32-bit)

Reply #26 –
I do not know the specifics. 

One potential argument for 96 kHz, is that you might also have higher resolution PCM files that have once been through DSD and then converted to PCM (by the digital store) - and who knows whether they applied a reasonable filter. I checked one that was recently posted here, and that seems to be filtered well, but do you really want to check everything when there is a quick fix?

Re: BUG foobar2000 v2.24.2 (32-bit)

Reply #27 –
Quote from: Air KEN on
foobar2000 users around the world are surprised that foobar2000 "does not support Native DSD playback using the Super Audio CD Decoder (foo_input_sacd)."
Where did you get this from? I said "DSD playback is not natively supported by foobar2000." That means that out-of-the-box DSD playback does not work in foobar2000.

Re: BUG foobar2000 v2.24.2 (32-bit)

Reply #28 –
Quote from: Porcus on
Quote from: wojak on
What exactly is the problem of converting to higher rate without filtering? Why filtering/brick-walling after the conversion is not good?
You can do that! The problem is if the user converts to too high sampling rates, and sends a signal that should be filtered, out without filtering.
Majority of DSD signal is noise. Without filtering you are just drowning the signal in ultrasonic noise. You really must remove it or you risk introducing bad aliasing artifacts to audible range. And some people seem to claim audiophile gear tweeters are very fragile and can break, so if that's true you will also risk breaking fragile hardware.

Re: BUG foobar2000 v2.24.2 (32-bit)

Reply #29 –
Quote from: wojak on
So "only":) PCM vs. DSD performance would matter.
As I linked the arcimage's measurements, your DAC chip has better frequency response, better signal-to-noise ratio, better channel separation and less intermodulation distortion in PCM mode than in DSD mode. If audio performance matters, you would play everything as PCM.

Quote from: wojak on
How do you know/see all those hacks in the component? Are they visible in the code (which I can't read) or are they visible in some crashes etc. sent to foobar stuff?
They are visible in the sources. I wouldn't have taken a look but issues people have reported and weird issues I have seen have forced to take a peek.

Quote from: wojak on
As a side note: If a component hacks the main program - it sounds scarry - shouldn't it be "banned" (which I would not want to happen)? But then again - many people want to play DSD so foobar should have innate/first party DSD and ASIO+DSD options replacing those banned.
Yes, such things really should not be done and if Peter was younger, he would have banned it long ago. Some of the things he has done he could have asked for legit SDK ways to achieve. But Peter is nice, he has allowed the component to exist without any trouble done to it as he knows there are people who wouldn't survive without it.

Quote from: wojak on
Would FFMPEG decoder wrapper work with sacd.iso? I was not able to find any chart related to ffmpeg arguments like -i %s -af - where do I find it (especially %s)?
I don't think FFmpeg can do ISO, sorry.
The %s part in '-i %s' comes from foobar2000, %s means source file. Generally not needed with FFmpeg wrapper, but documented here: https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Components_0.9/FFmpeg_Decoder_Wrapper_(foo_input_ffmpeg)#Additional_arguments

Quote from: wojak on
It is another place where foobar 2.25 is mentioned - yet I have not seen any previews or news about it -!?
AndreaT seems to have internal alpha access to help with early debugging before things go public. It's not yet ready for public consumption, planned features are still missing. It will be released on the home page when it's mature enough. Wouldn't be nice if public users for example got their configs nuked because design plans change.
 

Re: BUG foobar2000 v2.24.2 (32-bit)

Reply #30 –
Quote from: Case on
(...) It for example breaks completely unrelated UPnP playback abilities of the internal foobar2000 2.25 version (...)
The "internal foobar2000 2.25 version" is not yet officially announced, I guess?... Ca we expect any "beta-tests" soon?...