HydrogenAudio

Hello

SACD DSD is pulse density modulation, CD PCM is pulse code modulation.
Can there really be a lossless conversion from DSD to PCM?

Yes it can, and anyone can verify it.
I have tested it with DSD64.

Software:
foobar2000 1.4.4
foo_input_sacd-1.4.3
FLAC 1.3.3 x64
Musepack SV8 1.30.0

Settings:
SACD Converter DSD2PCM Mode: Direct (32fp, 30kHz lowpass)
"DoP for Converter" - Off

Converting DSD source to FLAC creates 24/44.1 files - around 4,3 times smaller than DSD source file.

FLAC compression -8
Musepack -standard (I use it because i like it, it doesn't matter which codec is used)

Foobar2000 displays Audio MD5 for FLAC files but not for SACD ISO or DSD files.
So there is now way to compare it.

But

Converting DSD Source -> FLAC -> Musepack -> FLAC

and

Converting DSD Source -> Musepack -> FLAC

Give us opportunity to check the Audio MD5 in final FLAC files.
And to my surprise final FLAC's all have the same Audio MD5 checksum.

So it means that converting DSD Source to FLAC is 100% lossless conversion.


Paweł

Um, I might be wrong, but doesn't "SACD Converter DSD2PCM" convert DSD to PCM?
That process is lossy in the way that it can't be used in reverse to get the same input file. Especially with lowpass filter.
As far as I am aware, DSD to PCM is lossy, but! you can use commandline wavpack to compress DSD files into wv files without conversion into PCM.

And to my surprise final FLAC's all have the same Audio MD5 checksum.

So it means that converting DSD Source to FLAC is 100% lossless conversion.

I fail to see how comparing the MD5s of different FLAC files proves that the conversion to FLAC was lossless. Perhaps you can try to explain it again using a different wording?

ktf

1 DSD source file converted:

First conversion
Converting DSD Source -> FLAC -> Musepack -> FLAC

Second conversion
Converting DSD Source -> Musepack -> FLAC

Both output FLAC files have same MD5 cheksum.



itisljar


Replaygain has exactly the same values for DSD source and FLAC encoded directly from DSD source.
I understand that DSD2PCM convert and it stands to reason that I check md5 of that output as source not DSD.
But exactly same values with replaygain say that this is very "exact" conversion.
Making 16 bit flac output gives differences from 0.000002 to 0.000012 peak values, 24 bit flac's are exactly the same.
I have tested also DSD256 now with same results.
If this is not lossless than it must be very very close.
I need pcm files since I use WASAPi output and have a headphone crossfeed in f2k dsp chain.
Can't use it with dsd, thus having pcm from dsd with same quality is what I need.
What I'm really looking for is empirical way to compare source to encoded flac.
If anyone has a better way to do it I would love to test it and see how close it gests.

Thank you.

There are free applications (see below) available to convert single-rate DSF>DFF, DFF>24/88 PCM, then PCM>DFF.  If lossless, wouldn't the MD5 be the same for the two DFF files?  They were not for me.

TASCAM Hi-Res Editor: https://tascam.com/us/product/hi-res_editor/download
PCM-DSD Converter: https://pcmdsd.com/Software/PCM-DSD_Converter_en.html
Free DSD64 (DSF) Sample Files: http://www.2l.no/hires/

ktf

1 DSD source file converted:

First conversion
Converting DSD Source -> FLAC -> Musepack -> FLAC

Second conversion
Converting DSD Source -> Musepack -> FLAC

Both output FLAC files have same MD5 cheksum.

itisljar

Replaygain has exactly the same values for DSD source and FLAC encoded directly from DSD source.
...

You compare the same things.
foobar does the same thing on both conversations plus the lossless flac step afaik.
First conversion
Converting DSD Source -> PCM -> FLAC -> Musepack -> FLAC

Second conversion
Converting DSD Source -> PCM -> Musepack -> FLAC

Also my guess is foobars Replaygain doesn't scan the DSD but a PCM conversation of it so it has to be the same as the flac.

Quote from: dev on 2021-12-25 20:13:04

ktf

1 DSD source file converted:

First conversion
Converting DSD Source -> FLAC -> Musepack -> FLAC

Second conversion
Converting DSD Source -> Musepack -> FLAC

Both output FLAC files have same MD5 cheksum.

itisljar

Replaygain has exactly the same values for DSD source and FLAC encoded directly from DSD source.
...

You compare the same things.
foobar does the same thing on both conversations plus the lossless flac step afaik.
First conversion
Converting DSD Source -> PCM -> FLAC -> Musepack -> FLAC

Second conversion
Converting DSD Source -> PCM -> Musepack -> FLAC

Also my guess is foobars Replaygain doesn't scan the DSD but a PCM conversation of it so it has to be the same as the flac.

You are probably right.

There are free applications (see below) available to convert single-rate DSF>DFF, DFF>24/88 PCM, then PCM>DFF.  If lossless, wouldn't the MD5 be the same for the two DFF files?  They were not for me.

TASCAM Hi-Res Editor: https://tascam.com/us/product/hi-res_editor/download
PCM-DSD Converter: https://pcmdsd.com/Software/PCM-DSD_Converter_en.html
Free DSD64 (DSF) Sample Files: http://www.2l.no/hires/

Thank you, will check them out.

The conversion is not lossless, and your test is flawed the moment you use fb2k on something that cannot be contained in 32-bit floating-point - that is what fb2k uses internally. That is, anything played back by foobar2000 - or converted by foobar2000 - is first projected down to what can be fit in a 32-bit floating-point PCM file, whether that processing is lossy or lossless. When converting from DSD-in-wavpack (see below), it warns you about the lossiness.

Using flac further converts to 24-bit integer, so there is a simple way to decide that the conversion to FLAC is lossy: compare the FLAC to a 32-bit floating-point .wav, and compare.

Now the 32-bit floating-point is not in itself lossless. But it can contain everything a 24-bit integer can, so had the 24-bit been lossless, they would have been identical.


WavPack has a mode to compress "undecoded" DSD losslessly, but you cannot do that by way of fb2k (because fb2k will decode it first and then pass it on, creating something bit-identical to a 32-bit floating-point PCM which isn't lossless).
The command-line to compress it:
wavpack.exe filename.dsd
returns a file filename.wv . Or instead give options:
wavpack.exe -mh --import-id3 filename.dsd
The latter transfers id3v2.3 tags from the DSD (not yet v2.4); the "h" improves compression; the "m" writes an audio md5 which you can read off in foobar2000. It will not match the FLAC md5.

But the FLAC md5 is the decoded PCM - which the DSD md5 is not (simply because that would be an md5 of a lossy conversion!)
And you cannot use foo_bitcompare, because that will not compare the DSD with the 32-bit floating-point file; it will first convert the DSD to the 32-bit floating-point and compare that to another 32-bit floating-point with the same audio.


There is no reason to use FLAC either. Some sizes:
30.9 MB for 2L-056_03_stereo_DSD64.dsf from the above 2L testbench
14.7 MB for the .wv compressed with -h
115 MB for a .wav (floating-point) as converted by fb2k from the .wv; it warns you that it isn't lossless!
61.7 MB for a .wv created from the previous file.

... wait. There is something here that just doesn't hold up. fb2k reports DSDs as if they were 24 bit and converts them as such as well. No difference to fb2k-generated 32-bit float - but the difference to ffmpeg-generated 32-bit float than can be explained by ...

What is going on?

No difference to fb2k-generated 32-bit float - but the difference to ffmpeg-generated 32-bit float than can be explained by ...

Different DSD-to-PCM converters, obviously.

You can't even convert 32-bit WAV/AIFF to FLAC, how can you convert DSD to it?

DSD can only be converted to FLAC if you convert it to PCM first, which is a lossy process. If you want to compress DSD losslessly, the only options are the incredibly slow reference codec, DST, and the way speedier WavPack.

... wait. There is something here that just doesn't hold up. fb2k reports DSDs as if they were 24 bit and converts them as such as well. No difference to fb2k-generated 32-bit float - but the difference to ffmpeg-generated 32-bit float than can be explained by ...

What is going on?

To be honest I hate DSD but since the cd versions have lower dynamic range masters then what they put on sacd.
It's hard not go for them, but they are pain in the... to use them even for end user.

Being stubborn I have found very useful tool "sacd-0.10.7"
It uses "Weiss Saracon" to convert dsd to pcm.
It does so in 2pass after first pass it calculates gain with "r128gain" and applies calculated gain to final output.
It's minimalistic, easy and simple to use.
Supposedly Saracon is one of the best converters.

Supposedly Saracon is one of the best converters.

Maybe… but the difference between those converters is probably miles beyond our threshold of hearing so I wouldn't really care about it. You probably have to rely on metrics to make any difference. Archimago did one comparison several years ago:

http://archimago.blogspot.com/2015/04/analysis-dsd-decoders-2015-windows-mac.html

(this test is a bit outdated: foobar2000's wasn't tested with the more popular and advanced foo_input_sacd; but Weiss Saracon's converter was included: it wasn't already the best converter at this time. In the meantime EZ CD Audio Converter also add its own converter with two quality modes — could be worth to check it).

Audiofools with a lot of money to spend may only trust HQ Player (which costs up to 3,561.20 USD… only for resampling  ;D ) and insanely slow algorithms. It was also tested by Archimago:
http://archimago.blogspot.com/2019/02/measurements-look-at-hqplayer-325.html

For completenes i use SoX for DSD decoding. Since it uses SoX resampling treating DSD as 1bit fed to it i can use all options i got used together with SoX. I guess used together with the ultra value and its even higher stoppband it theorertical outperforms the other solutions.

To be honest I hate DSD but since the cd versions have lower dynamic range masters then what they put on sacd.

SACD in a nutshell: its only reason to be (from consumer's point of view), is those few better masters they made only to sell it. Wonder if that remastering happened more than a few times to fool consumers into thinking that the format itself sounds better.

So in *checks notes* 2004 (when SACD was halfway dead already) there came about the "DXD" format that was 352.8 kHz/24 bits. If you go to http://www.2l.no/hires/ you will see that most of those files are originally DXD.
Which begs the question really: in converting DSD to 352.8/24 FLAC, how much is lost of anything that was in the original 352.8/24 PCM?
I.e. considering the lossy roundtrip PCM->DSD->PCM and comparing to the original PCM: does the second conversion discard information that isn't already wrong? Sure there is a chance of another roundoff error, but there shouldn't be more. Yet the foo_bitcompare results are more on par with MP3'ing a CD ...
(Compare to precisely that: Make an MP3 from CDDA, and decode the MP3 to PCM; if you first decode to 32-bit float and then to 16-bits integer, the second conversion is lossy, but what does it discard? There shouldn't have been anything in bits 17 ff, should it? Assume for simplicity that peak volume is meticulously kept so that no clipping is introduced ...)

Studio processing to end-user format is anyway not supposed to be a lossless operation.

Quote from: dev on 2021-12-27 12:35:00

To be honest I hate DSD but since the cd versions have lower dynamic range masters then what they put on sacd.

SACD in a nutshell: its only reason to be (from consumer's point of view), is those few better masters they made only to sell it. Wonder if that remastering happened more than a few times to fool consumers into thinking that the format itself sounds better.

Don't even get me started :)
I think that they convert files around in masters without really caring about how much is lost.

guruboolez, thank you for the links, you have made my day :)
Yes, those programs make overkill quality files.
I look at it like "do it once, and forget".
Studio quality 16/44.1 audio.

Yes, there is a lot of nonsense when it comes to audiofools, worst is that marketing slogan has more power than technical data to some.
But it's a good way of making money.

Quote from: dev on 2021-12-27 12:35:00

Supposedly Saracon is one of the best converters.

Maybe… but the difference between those converters is probably miles beyond our threshold of hearing so I wouldn't really care about it. You probably have to rely on metrics to make any difference. Archimago did one comparison several years ago:

http://archimago.blogspot.com/2015/04/analysis-dsd-decoders-2015-windows-mac.html

(this test is a bit outdated: foobar2000's wasn't tested with the more popular and advanced foo_input_sacd; but Weiss Saracon's converter was included: it wasn't already the best converter at this time. In the meantime EZ CD Audio Converter also add its own converter with two quality modes — could be worth to check it).

Audiofools with a lot of money to spend may only trust HQ Player (which costs up to 3,561.20 USD… only for resampling  ;D ) and insanely slow algorithms. It was also tested by Archimago:
http://archimago.blogspot.com/2019/02/measurements-look-at-hqplayer-325.html

Archimago's latest tests showed that ESS's flagship ES9038 chips always degrade DSD input, any upsampling effort with external software is useless. Read the links sequentially for details:
https://archimago.blogspot.com/2021/10/measurements-look-at-dsd-and-using-sox.html
https://archimago.blogspot.com/2021/10/measurments-dsd-testing-with-sox-dsd.html
https://archimago.blogspot.com/2021/10/revisiting-teac-ud-501-dac-2013-thdn.html

For completenes i use SoX for DSD decoding. Since it uses SoX resampling treating DSD as 1bit fed to it i can use all options i got used together with SoX. I guess used together with the ultra value and its even higher stoppband it theorertical outperforms the other solutions.

Something like this:
https://www.audiosciencereview.com/forum/index.php?threads/digital-filter-game.23795/post-810355
More like flexibility rather than extremely slow settings.

Something like this:
https://www.audiosciencereview.com/forum/index.php?threads/digital-filter-game.23795/post-810355
More like flexibility rather than extremely slow settings.

Thanks for sharing this link :)

Something like this:
https://www.audiosciencereview.com/forum/index.php?threads/digital-filter-game.23795/post-810355
More like flexibility rather than extremely slow settings.

Nice! I only have DSD64 and indeed keeping to much bandwith makes no sense. 88.2kHz sampling and the 74% bandwidth is already plenty.

Compare to precisely that: Make an MP3 from CDDA, and decode the MP3 to PCM; if you first decode to 32-bit float and then to 16-bits integer, the second conversion is lossy, but what does it discard? There shouldn't have been anything in bits 17 ff, should it?

I don't know the details of mp3 inner workings but I'd say it should. I assume that in the encoded form mp3 is a bunch of parameters, that during decoding are used to reconstruct a PCM which should be perceptually similar to the input. If there was an additional constraint, that the values of the parameters are such that the decoded PCM falls within 16 bit bounds, the whole thing would be more complex and probably less efficient, size-wise.

I don't know the details of mp3 inner workings but I'd say it should.

I was unclear. There is nothing in the original source below 16 bits. Sure an MP3 will have noise below that if it makes for better compression at given quality, or better quality at same file size.

Question is: Given that the MP3 comes from CDDA,
* Decoding the MP3 to [big number] bits is surely transparent.
* Now reduce further to 16 bits. Would there be any value in what you discard?

To any answer based on "16 is more than enough": Let's repeat the question then with an N-bit original signal for some suitable N<16. Like 12? I am not sure what the answer would be, I'm too lazy to do all the testing (and it would be better done by younger ears I think).

I was unclear. There is nothing in the original source below 16 bits. Sure an MP3 will have noise below that if it makes for better compression at given quality, or better quality at same file size.

Question is: Given that the MP3 comes from CDDA,
* Decoding the MP3 to [big number] bits is surely transparent.
* Now reduce further to 16 bits. Would there be any value in what you discard?

To any answer based on "16 is more than enough": Let's repeat the question then with an N-bit original signal for some suitable N<16. Like 12? I am not sure what the answer would be, I'm too lazy to do all the testing (and it would be better done by younger ears I think).

Since it is a DSD and flac thread I think it can be explained in this way:

Everyone knows that DSD only has 1-bit but it can have more than 20 effective bits below 22kHz. It is achieved by averaging a lot of 1-bit samples to approximate the desired amplitude value. All complexities are in the encoding process -- deciding how to arrange a bunch of 1-bit samples to achieve the desired result.

How relevant is it to your question? Encoding a 16/44 file to MP3, and decode to 16/44 vs a higher bit-depth?

I attached the original 16/44 file and the mp3 file, and here are the results of different decoding settings, all were done with foobar2000. foobar2000 only provides a strongly shaped dither, so I also used Case's Smart dither (https://www.foobar2000.org/components/view/foo_dsp_dither) in the illustration. The original file contains a -120dB 3kHz tone. Among the decoded files, the undithered 16-bit file showed obvious amplitude error.


Zoomed screenshot to show the 3kHz tone's amplitude.


The results can be interpreted in this way: if the decoded 16-bit file is dithered from a higher bit-depth, the averaged effective bit-depth in the 16-bit decoded file can be preserved in a better way.

Hi, let me put some pictures too.
Source from Saracon Signal Generator 1kHz test tone (included in archive).
Encoded to WAV with Saracon, foobar2000 (dither in converter when used), EZ_CD_Audio_Converter.
Click on the picture to see the software and options used.

(https://i.ibb.co/znbrBc1/EZ-CD-Audio-Converter-16-Ultra-High-no-dither.png) (https://ibb.co/znbrBc1) (https://i.ibb.co/2hBT0bg/EZ-CD-Audio-Converter-16-Ultra-High-TPDF.png) (https://ibb.co/2hBT0bg) (https://i.ibb.co/gPgNXm3/EZ-CD-Audio-Converter-24-Ultra-High-no-dither.png) (https://ibb.co/gPgNXm3) (https://i.ibb.co/fD114R9/foobar2000-Direct-32fp-30k-Hz-lowpass-16-dither.png) (https://ibb.co/fD114R9) (https://i.ibb.co/2WCtFBd/foobar2000-Direct-32fp-30k-Hz-lowpass-16-no-dither.png) (https://ibb.co/2WCtFBd) (https://i.ibb.co/VDsxWWT/foobar2000-Direct-32fp-30k-Hz-lowpass-24-no-dither.png) (https://ibb.co/VDsxWWT) (https://i.ibb.co/jVZ1ZBR/foobar2000-Multistage-32fp-16-dither.png) (https://ibb.co/jVZ1ZBR) (https://i.ibb.co/BfnQLN5/foobar2000-Multistage-32fp-16-no-dither.png) (https://ibb.co/BfnQLN5) (https://i.ibb.co/h8d3D5Y/foobar2000-Multistage-32fp-24-no-dither.png) (https://ibb.co/h8d3D5Y) (https://i.ibb.co/yWGK3j1/Saracon-16-no-dither.png) (https://ibb.co/yWGK3j1) (https://i.ibb.co/vmwD7wZ/Saracon-16-TPDF.png) (https://ibb.co/vmwD7wZ) (https://i.ibb.co/fQ110p2/Saracon-24-no-dither.png) (https://ibb.co/fQ110p2)


A picture is worth a thousand words.

Wrong EZ CD Audio converter sampling rate, sorry for that; those pictures and archive are correct.

(https://i.ibb.co/HpdLF7n/EZ-CD-Audio-Converter-16-Ultra-High-no-dither.png) (https://ibb.co/HpdLF7n) (https://i.ibb.co/z4yx975/EZ-CD-Audio-Converter-16-Ultra-High-TPDF.png) (https://ibb.co/z4yx975) (https://i.ibb.co/6n1rXjJ/EZ-CD-Audio-Converter-24-Ultra-High-no-dither.png) (https://ibb.co/6n1rXjJ) (https://i.ibb.co/fD114R9/foobar2000-Direct-32fp-30k-Hz-lowpass-16-dither.png) (https://ibb.co/fD114R9) (https://i.ibb.co/2WCtFBd/foobar2000-Direct-32fp-30k-Hz-lowpass-16-no-dither.png) (https://ibb.co/2WCtFBd) (https://i.ibb.co/VDsxWWT/foobar2000-Direct-32fp-30k-Hz-lowpass-24-no-dither.png) (https://ibb.co/VDsxWWT) (https://i.ibb.co/jVZ1ZBR/foobar2000-Multistage-32fp-16-dither.png) (https://ibb.co/jVZ1ZBR) (https://i.ibb.co/BfnQLN5/foobar2000-Multistage-32fp-16-no-dither.png) (https://ibb.co/BfnQLN5) (https://i.ibb.co/h8d3D5Y/foobar2000-Multistage-32fp-24-no-dither.png) (https://ibb.co/h8d3D5Y) (https://i.ibb.co/yWGK3j1/Saracon-16-no-dither.png) (https://ibb.co/yWGK3j1) (https://i.ibb.co/vmwD7wZ/Saracon-16-TPDF.png) (https://ibb.co/vmwD7wZ) (https://i.ibb.co/fQ110p2/Saracon-24-no-dither.png) (https://ibb.co/fQ110p2)

Your Saracon .wav files contain a lot of zero samples at the end. You have to trim those samples so that RMAA can render the FFT plots correctly. I trimmed the 24-bit file for you and now the plot looks like this:


Also, foobar's "Direct" and "Installable" modes are not intended to be used with very high decimation ratios (DSD64 > 44.1k = 64x decimation). You can even identify in your 24-bit foobar screenshot, the 24-bit noise floor is somewhat wiggling and not as clean as multistage, EZ-CD-Audio-Converter and my corrected screenshot of Saracon. "Direct" is simply "Installable" without a user-selectable filter, and none of the bundled installable filters is suitable for more than 32x of decimation. You can see my tests here:
https://www.audiosciencereview.com/forum/index.php?threads/the-sound-quality-of-dsd.14773/page-24

You can see that these filters have around 44-50kHz of stopband. Ideal stopband for 44.1kHz sample rate should be at around 22kHz. An ideal installable filter for 64x decimation will be very long (several thousand samples) and conversion speed will be much slower than multistage.

So, going dsd64 to 44.1 pcm degrades signal?

So, going dsd64 to 44.1 pcm degrades signal?

SACD DSD is pulse density modulation, CD PCM is pulse code modulation.

That's unimportant and irrelevant. The main point is sample rate. FLAC supports up to 655350Hz, and DSD64 is 44100 * 64 = 2822400Hz. As long as the sample rate is not identical, the conversion will not be lossless. As mentioned earlier the principal of DSD is averaging a lot of 1-bit samples. You can have several numbers arranged in different orders that average to the same single number, for example:
1, 2, 3
2, 2, 2
3, 2, 1
...and so on, they all have an average of 2. But given a "2" and decompose to 3 discrete values, there is no way to know which three values in which order is the original one. It is not a reversible process, and therefore lossy, or "degrades", no matter how small the degradation is, audible or not.

I understand what your saying.
I know it can't be bit perfect, but it can be sonic "perfection" - precision; as close as possible to the source.
This is what I'm looking for; dsd to 16/44.1 pcm, best software that can make it possible.

And digital silence :)
Generated in Audacity, dsd64 in Saracon.
DSD64 to 16/44.1 in Saracon, Foobar2000 and EZ CD Audio Converter


(https://i.ibb.co/pfxPD76/EZ-CD-Audio-Converter-16-Ultra-High-TPDF.png) (https://ibb.co/pfxPD76) (https://i.ibb.co/56ppgNn/silence-16-dither-foobar2000-Direct-32fp-30k-Hz-lowpass.png) (https://ibb.co/56ppgNn) (https://i.ibb.co/XVPcNcN/silence-16-TPDF-Saracon.png) (https://ibb.co/XVPcNcN)

The main point is sample rate. FLAC supports up to 655350Hz, and DSD64 is 44100 * 64 = 2822400Hz.

Came to think of: According to https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats#Technical_details  both  TTA and MPEG-4 ALS support up to 4 GHz sample rate and 1-bit resolution.

I attached the unfiltered 2822400Hz .wav file converted from the Saracon .dff file that @dev attached. It can be loaded into foobar, Audacity and so on.

Track 1: unfiltered
Track 2: 600kHz cutoff
Track 3: 200kHz cutoff

bennetng, you must be more precise at what your getting at.

A great article about DSD and comparisons between PDM and PCM is here: https://digital-audio-systems.com/pcm-im-vergleich-zu-dsd/
Unfortunatelly, the article is in German, but I'm guessing you could use Google translate.

The comparisons are taken directly from the suggestions made by Sony and Philips. Philips suggest doing production in PCM with 32B/352.8kHz (which is an even greater bit depth than DXD, which is 24B/352.8kHz). Sony suggests using "DSD-Wide" which is 4 or 8 bit PCM at DSD sampling rates.

PDM is in itself kinda interesting, I find the noise shaping characteristics and things like information density intriguing, but from a practicality standpoint, it seems to be more of a meme than anything. Also, a study (http://sdg-master.com/lesestoff/gesamtarbeitneu.pdf) found that there are no discernible differences to High-Res PCM at 24B/176.4kHz.
The "problematic" noisefloor above 15kHz removes the practicability of DSD/PDM further, such that PDM has a SNR of 120dB with modern encoders, and hence less than 24B PCM (which has 144dB SNR).

Pretty much no DSD production is creates only in DSD, this is pretty much impossible, if any audio editing is to be performed - which is almost always the case. And I don't remember ever having seen a direct-to-disk DSD recording.

Also, why even stop at DSD64, there's DSD512, too.

polemon, it's a good read, thanks.
Haha, I have to say it again i hate dsd :)

Did the PDM/PWM thing on disc emerge in the "1-bit Delta-Sigma DACs to everyone" bandwagon, or am I just confusing the timeline? Anyway, it is beyond limits of human hearing since long ...

Philips suggest doing production in PCM with 32B/352.8kHz (which is an even greater bit depth than DXD, which is 24B/352.8kHz).

Floating-point makes sense in processing. 32-bit float can losslessly contain whatever was stored in 24-bit integer, and storage is cheap.

Did the PDM/PWM thing on disc emerge in the "1-bit Delta-Sigma DACs to everyone" bandwagon, or am I just confusing the timeline? Anyway, it is beyond limits of human hearing since long ...

Well, ΔΣ isn't even used anymore in favor of other encoding systems.

Floating-point makes sense in processing. 32-bit float can losslessly contain whatever was stored in 24-bit integer, and storage is cheap.

I'm not sure they meant 32-bit float. Perhaps they did, but then they could've just specified 32-bit floating point. Instead the "32 bit" sounds a lot like 32 bit of a singed long int to me instead of double. Might be wrong though.

bennetng, you must be more precise at what your getting at.

Sure. A more precise one. Just lower the cutoff frequency. Anyway, a screenshot only has several hundred pixels of resolution, it is just an illustration of the averaging in action.

Quote from: dev on 2022-01-03 06:26:27

bennetng, you must be more precise at what your getting at.

Sure. A more precise one. Just lower the cutoff frequency. Anyway, a screenshot only has several hundred pixels of resolution, it is just an illustration of the averaging in action.
[attach type=image]21643[/attach]

Let me rephrase it, I don't understand the point that you are making, and I would like to :)

Let me rephrase it, I don't understand the point that you are making, and I would like to :)

So that people who are interested can try to inspect and process the file at the original sample rate themselves, including lurkers and other participants.

Quote from: dev on 2022-01-03 11:24:56

Let me rephrase it, I don't understand the point that you are making, and I would like to :)

So that people who are interested can try to inspect and process the file at the original sample rate themselves, including lurkers and other participants.

Roger that.
Thank you.

Did the PDM/PWM thing on disc emerge in the "1-bit Delta-Sigma DACs to everyone" bandwagon, or am I just confusing the timeline? Anyway, it is beyond limits of human hearing since long ...

Quote from: polemon on 2022-01-03 10:08:34

Philips suggest doing production in PCM with 32B/352.8kHz (which is an even greater bit depth than DXD, which is 24B/352.8kHz).

Floating-point makes sense in processing. 32-bit float can losslessly contain whatever was stored in 24-bit integer, and storage is cheap.

1-bit SDMs were popular in the 90s. Multibit SDMs are more popular nowadays. Just find the datasheets from chipmakers like AKM, Cirrus, ESS, TI. For older products, this website has a pretty comprehensive list:
http://stephan.win31.de/dac-adc-hist.htm

With 1-bit, everything solely relies on averaging of merely two extreme values, with more bits, you can utilize more amplitude values plus averaging. In fact, even typical PCM dithering methods contain values at +1, 0 and -1. With DSD, there is no 0, silence is encoded with sequences of +1 and -1, and often result in audible clicks during track change.

It's just an evolution of IC technology like CPUs. Instead of simply increasing frequency, they also have more cores, more SIMD extensions, better floating point support and so on.