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: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM (Read 482 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Hello!

Recently I wanted to compress some of my DSD (.dsf) collection with WavPack. The encoded files play well in foobar2000 with foo_input_sacd as DSD stream, but when playing as 24bit 352.8kHz PCM, there were clicks/pops at the beginning of almost every track. I'm quite sure that my .dsf files are good as they came directly from an online music store, and they work well with my DAP. So I did the following test:

 • Play and output the .dsf files directly to a DAC - no clicks and pops;

 • Unpack the .wv files and force output to WAV format using WvUnpack, then play the .wav files with foobar2000 - clicks/pops occurred;

 • Apply a 30kHz lowpass filter to the .wav files using SoX, then play the processed files with foobar2000 - clicks/pops persist;

 • Trim the .wav files using SoX to keep only the first 0.125 seconds and inspect the spectrogram with Spek - found a weird vertical "blue bar" (please see attached screenshot as an example, all the tracks I tested have this "blue bar");

 • Apply a fade-in effect to the first 8 samples of the 24bit 352.8kHz PCM files (using SoX), then play with foobar2000 - the clicks/pops disappeared!

So I wonder if this is due to WavPack did not handle the DSD to PCM conversion correctly, or if I did something wrong in the process? And how to fix this?

Thank you  :)

Re: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Reply #1
Are there clicks if you don't use WavPack at all and simply play your unpacked .dsf files as 24/352 PCM via foo_input_sacd?

Re: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Reply #2
Are there clicks if you don't use WavPack at all and simply play your unpacked .dsf files as 24/352 PCM via foo_input_sacd?

Hi bennetng - I just tested, and the result is No. I tried Multistage mode and Direct mode, as well as different sample rates and gain settings. None of the scenarios has audible clicks.

Re: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Reply #3
Thanks for posting this! I should have posted earlier because I know what’s going on, but I was hoping I’d get a chance to experiment with a fix (I haven’t yet).

Unfortunately, using WavPack’s built-in DSD to PCM conversion is not ideal because it uses a filter with a length of 56 DSD samples, which is 7 DSD “bytes”. Each “byte” of DSD data generates one 24-bit output PCM sample, which means that when converting a file there are 6 samples in the beginning that cannot be accurately converted because we have no history from the previous file. This means that gapless playback is never going to be perfect using this facility (I believe that foo_input_sacd does the PCM conversion itself, outside the file boundaries).

One solution to this would be to simply discard those 6 samples and have the PCM version slightly shorter than it should be. I didn’t really like that because it would mean, for example, that the length of a PCM conversion would change with different filters, and perhaps different versions of the decoder. Not ideal.

So I decided to pre-fill the filter with DSD silence and generate those 6 samples anyway, figuring that at least the silent gap case would be glitchless and the correct length. The problem is that unlike PCM, with DSD there are different flavors of digital silence. I used a single byte pattern of 0x55, but I have seen others. For example the DSD file in my test suite uses a 5-byte pattern of 0xD3, 0x2C, 0xD2, 0xD2, 0xD2.

What I didn’t realize until now was that if you transition from one flavor of DSD silence to another, it can generate a glitch that extends down into the audible band. Here’s what you get transitioning from the 0x55 “silence” to the 5-byte version:



In your spectral view of the audio, the “blue bar” is simply that 6-sample glitch (it would have actually been easier to see in waveform mode).

In any event, I’ll be experimenting a little with solutions that aren’t too ugly. But in the meantime you can rest assured that there’s nothing wrong with your WavPack files (especially if you created them with the -v option!) and the clicks are just an artifact of the files being independently converted to PCM before being stitched together. Obviously if you have the ability it’s better to play them natively.

If you wouldn’t mind, I’d appreciate getting the very beginning of those DSD files to find out what “silence” they are using. You are the first person to report hearing this, so there may be something additional going on. Probably the easiest way would be to use the “--until” option of wvunpack to do that, something like this:

wvunpack --dff --until=0:1.0 dsdfile.wv -o dsdfile-1sec.dff

(and of course you can WavPack that again to reduce the size).

Thanks!



Re: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Reply #4
One solution to this would be to simply discard those 6 samples and have the PCM version slightly shorter than it should be. I didn’t really like that because it would mean, for example, that the length of a PCM conversion would change with different filters, and perhaps different versions of the decoder. Not ideal.

You can discard these samples and then pre-extrapolate the signal (see e.g. https://datatracker.ietf.org/doc/html/rfc7845#section-7 )

Re: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Reply #5
Unfortunately, using WavPack’s built-in DSD to PCM conversion is not ideal because it uses a filter with a length of 56 DSD samples, which is 7 DSD “bytes”. Each “byte” of DSD data generates one 24-bit output PCM sample, which means that when converting a file there are 6 samples in the beginning that cannot be accurately converted because we have no history from the previous file. This means that gapless playback is never going to be perfect using this facility (I believe that foo_input_sacd does the PCM conversion itself, outside the file boundaries).

When converting a 2.8 MHz DSD to a 24/352.8 PCM, I guess the number of samples in the output file should be 1/8 as the number of samples in the input file. I tried some conversion previously with foo_input_sacd, WavPack, and FFmpeg. Looks like WavPack is the only one among the three whose output has the "correct" sample count. So I was under the impression that foo_input_sacd and FFmpeg's conversion is not as "accurate" as WavPack :D


One solution to this would be to simply discard those 6 samples and have the PCM version slightly shorter than it should be. I didn’t really like that because it would mean, for example, that the length of a PCM conversion would change with different filters, and perhaps different versions of the decoder. Not ideal.

One thing on top of my head is that some tracks do not start with silence, so discarding 6 samples may (or may not) cause additional glitches.


If you wouldn’t mind, I’d appreciate getting the very beginning of those DSD files to find out what “silence” they are using. You are the first person to report hearing this, so there may be something additional going on.

The attached zip file has the first 4 seconds and the last 4 seconds from 10 tracks, 20 files in total, including a 3-movement piece (Mozart's KV 181) where there's no pause between movements. I'm happy to provide more files if there's a need.

Update: Not sure why I can't attach the zip file so I put it on Google Drive (test_files.zip)

Re: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Reply #6
One solution to this would be to simply discard those 6 samples and have the PCM version slightly shorter than it should be. I didn’t really like that because it would mean, for example, that the length of a PCM conversion would change with different filters, and perhaps different versions of the decoder. Not ideal.

You can discard these samples and then pre-extrapolate the signal (see e.g. https://datatracker.ietf.org/doc/html/rfc7845#section-7 )
Yes, this is what I was planning. Thanks for the link! I'm hoping to get away with something simpler than LPC for generating just 6 samples, but we'll see...  :)

 

Re: Clicks/pops occur at the beginning of DSD wv tracks when playing as PCM

Reply #7
One solution to this would be to simply discard those 6 samples and have the PCM version slightly shorter than it should be. I didn’t really like that because it would mean, for example, that the length of a PCM conversion would change with different filters, and perhaps different versions of the decoder. Not ideal.

One thing on top of my head is that some tracks do not start with silence, so discarding 6 samples may (or may not) cause additional glitches.
No, you're absolutely right. Throwing away samples only fixes the silent gap case. There definitely will be a glitch if the transition is not silence and samples are removed, so I won't be doing that.

If you wouldn’t mind, I’d appreciate getting the very beginning of those DSD files to find out what “silence” they are using. You are the first person to report hearing this, so there may be something additional going on.

The attached zip file has the first 4 seconds and the last 4 seconds from 10 tracks, 20 files in total, including a 3-movement piece (Mozart's KV 181) where there's no pause between movements. I'm happy to provide more files if there's a need.
Thanks so much for creating these samples; it's way more than I expected!

I am able to hear the glitches in the silent transitions, but I could not hear them in the non-silent cases (although it was not an ideal listening environment). However, I can see them when I zoom in so I should be able to tell if I've fixed them sufficiently.