I continued my experiments with perverted audio formats and found file DSD1024 (x48kHz, not 44.1).
wavpack.exe version 5.1 is able to encode it to *.wv. And then wvunpack.exe is able to decode *.wv to *.w64 with PCM 24 bits / 6 144 000 Hz.
But foobar2000 is unable to decode wavpack file created from this DSD and is unable to play w64 (24 bits / 6 144 000 Hz) created with wvunpack.exe
DSD1024 file is available for free here - http://wechdomi.org/english/index.html
@kode54 might find the file interesting too. It manages to make foobar2000 v1.4 hang and v1.3.20 crash when playing it with foo_input_dsdiff.
Unrelated to the playback problem but I couldn't help posting. Take a look at the frequency spectrum, the file is nothing but noise:
(https://i.imgur.com/kJGQkPM.png)
@Case How did you decoded it? Actually it is NOT only noise. After decoding *.wv to *.w64 with wvunpack.exe i am able to play it with MPC-HC and LAV (with resampling of course) and there is music in it.
I didn't mean literally. Just the vast majority of it. If you look closely the bottom spectrum display shows a few pixels of dark colors at the bottom which is from the audible band. The tiny frequency plot window uses a different scale and shows that there is music in the file. Though amusingly the frequency response starts to drop after 1 kHz and by 10 kHz you are already at the background noise region. The decoded file comes from wvunpack.
Just continuing the off topic:
DSD needs to be low pass filtered to convert it to PCM.
I took all of the bits, changed them into text 1 or -1 per line, loaded them into Adobe Audition, filtered it to 80k with a 6th order Bessel filter, then downsampled from the 49,152kHz sample rate to 192kHz. It sounds OK (Oops Adobe Audition 3.0 only loaded the first 4 Gigs of the file)
flac on OneDrive
(https://1drv.ms/u/s!AtFak_rdfM14gYdegquaIU6VEurAmQ)
(https://1drv.ms/u/s!AtFak_rdfM14gYdegquaIU6VEurAmQ)(https://1a2pua.ch.files.1drv.com/y4mJAn243vIOvVuY4HZHDpohEPNtC5Cia9rkKdvmy8xrPykIBi7fJp6vAB88rxdiXIMVHqCwBEpKRB6wuIjN96l7GYPOEtq_43MziVo66Vm-Bn3YllqkdEFRpLXDdPwDsSyMmbmA_iXK7shOEw5KSALlM-rYDvfXKiyjhd6cvIhsaUlr--o_y3QsUwLO38OWiCwxCIjHW70DCPNeBqbdccQ7A?width=1024&height=814&cropmode=none)
Actually the easiest and fastest way to convert this file to easily playable PCM is ffmpeg with filter -af aresample=44100:resampler=soxr
foo_input_sacd 1.1.0 makes fb2k to crash with this file
I know, I just wanted to show that to analyze a DSD file with a PCM tool you just have to filter first.
foo_input_dsdiff is probably having problems because it attempts to use core resampler services to downsample the file to the configured sample rate. It only uses a built-in filter for the 8:1 DSD reduction, and it uses a pre-calculated table to convert the DSD byte at a time, into overlapped sample blocks.
Can I decode MQA using "FFmpeg Decoder Wrapper"? Only acts on the first unfold.
Does FFmpeg support MQA? I was not aware anyone had cracked it yet.
MQA is a still born garbage anyway, there's no reason for anyone to waste time on it. It solves none of the open problems in audio codecs if we assume they still exist.
@lvqcl - Noticed something weird here. I'm running alpha foobar2000 which has lifted the sample rate limit and your SoX resampler component can't manage realtime speed here. Even SRC does so something is definitely off. I don't think it's SoX issue as ffmpeg's filter shows no such problem.
Edit: perhaps some buffering issue? Wavpack version of the track resamples at 2x realtime speed but W64 version at 0.8x speed. Both report the same 6144000 Hz. Speed test component shows that WavPack is quite a bit slower to decode than W64 so resampling that should be slower too.
@Case - cannot confirm the issue. I converted that .dff file to .wv, then from .wv to .w64 (the resulting file is 8 GB long).
On my rather old 2.5 GHz Penryn the very first pass has low speed, 0.804 x realtime, all subsequent passes are ~2.8 x realtime.
On another, smaller file that can fit into RAM: 9.3 x realtime.
Decode speed test seems to show average speed as being fast enough for realtime playback for me too. I see the problem during playback and when I ran converter. But I hit Abort after a while.
I'll attach a small video so you can see and hear what I mean. I still use the old Core i7-4771.
@Case I limited sizes of some buffers and length of extrapolated signal. I hope the problem is fixed.
I have suspicion that soon 32-bit unsigned int won't be enough to store sample rates...
The track plays without glitching now. Thanks.