A toast to PGGB, a heady brew of math and magic

[Atriya]

For those using PGGB with a Chord Qutest (and this may be applicable to other Chord DACs as well): which filter button setting do you use on the Qutest?

 

The use of PGGB to upsample to 705/768Khz will disable the WTA1 filter on the Qutest, but whether the WTA2 filter is disabled or not will depend on whether the filter button is white (WTA2 enabled) or orange (WTA2 disabled). Do you find that the WTA2 filter works well with PGGB-d files (since it was really designed to be used on top of WTA1)? Personally I seem to prefer WTA2 disabled (orange), but that could just be because my system is slightly too bright (which it probably is).

 

Further, the green (WTA2) & red (no WTA2) filters additionally affect the operation of the 2048Fs stage that follows the 256Fs WTA2 filter. Do you use green instead of white and red instead of orange with all PGGB-d files, or only when the PGGB-d file was sourced from high-res PCM, or not at all? And of course PGGB itself has a HF noise filtering setting where you can choose "Full (21Khz)". Do you use this instead of/in addition to the green/red filters?

 

And finally, though maybe a bit off-topic, any differences to the above if and when you use HQPlayer for upsampling instead of PGGB? I'm guessing many of you use HQP for upsampling streaming content. 

[Atriya]

I wonder if there would be interest in a community database of music that works very well with PGGB, as a nice PGGB-inspired way of sharing/discovering music for all. If there is, I can set it up.

 

Part of my personal motivation in this is that despite quite some effort and some quite niche gear purchases (I use an SRC-DX), upscaling in general (PGGB or HQP) hasn't quite wowed me yet, even now with 160-bit processing. On some tracks I think I hear a slight improvement, on others I'm quite convinced that there is none at all. I could just give up and conclude that upscaling is not my thing, but I tend to treat it like one of those puzzle images where you have to look very hard to see some aspect of it: some people see it instantly, some only after a long time, but once you see it, it's hard to "unsee".

 

Now perhaps adifference between track outcomes is normal, which makes it all the more valuable to have a database of exemplary tracks, with notes from the contributor.

[Atriya]

On 5/28/2022 at 5:54 PM, Zaphod Beeblebrox said:

 

Yes of course we analyzed if the bits changed. I like to see objective data that corroborates a subjective change.

 

Below is a sample analysis for 80 second track, comparing 64-bit processing with 128bit processing with noise shaped output set at 32 bits. The X axis is the difference, so a difference of 100 is approximately 6.64 bits, Y axis is the probability (multiply by 100 to get percentage). The main takeaway is we saw up to a maximum of about 7 bits change and a majority of the samples changed. The analysis looks similar for 24 bit output.

 

Main thing to note is if instead of noise shaping if the reconstructed signal at 128 bit and 64 bits were just truncated to 24 bits or 32 bits, we noticed very little or no change. One way to look at this is that  noise shaping in a way lets more information to be encoded into a lower bit-depth.

 

 

A possibly related observation that I found interesting: the 64-bit and 128-bit processed WAV files have exactly the same file sizes, as one would expect. However, when I compress them losslessly using WavPack, the 128-bit-processed file is slightly larger. In my case it was about 8 MB of difference in a 450 MB compressed file. 

[Atriya]

1 hour ago, taipan254 said:

I’ve struggled to hear the difference as well. However I believe it is because my source is a dell laptop and not something quieter / purpose built for audio. I’ve done a ton of experimenting to no avail while others with the same DAC as mine swear by PGGB. 
 

I think PGGB is likely beneficial for folks with an already excellent playback chain (from power and server to amps and speakers). Mine likely needs work!

 

Maybe, maybe not. My chain is a Raspberry Pi 4B w/ linear power supply -> SRC-DX -> Chord Qutest w/ linear power supply -> Burson Soloist 3XP w/ supercharger 3A -> Hifiman Aryas, with "audiophile" cables used throughout (but not insanely expensive ones). About a year ago I was running from a laptop via USB, and my thoughts mirrored yours exactly; I eventually upgraded every single component of my system except the Qutest (and the Soloist was perhaps a side-grade from a transparency standpoint), only to still be in the same boat.

 

I do hear benefits, but only in highly specific things. For example (and this example is courtesy of the YouTuber "Passion for Sound" Lachlan), listen to the drumstick hits at the beginning of Nemesis by Benjamin Clementine. I hear an improvement with PGGB (Lachlan hears an improvement with the Chord M-Scaler). But on the same track, he hears an improvement in the quality of the piano ("harmonic richness"), and I don't hear any.

[Atriya]

Question for Zaphod: when using the new precisions higher than 64-bit, what is the best practice for outputting 64f-bit WAV files for digital volume control downstream? For noise shaping, should I select "Off" or "Dither only"?

 

Would the use of this intermediate 64f-bit stage, from which the software player (in my case HQPlayer) would apply noise shaping (in my case LNS15) down to 24-bits for the DAC, negate some or all of the benefits of 128-bit processing?

 

UPDATE: I noticed that even when "Dither only" is selected, the log file says: "-- > No dither or noise shaping <--". How exactly then are we going from 128 bits to 64 bits?

[Atriya]

8 minutes ago, Zaphod Beeblebrox said:

Yes dither and noise shaping is automatically turned off for 64 bits. higher precision floating point values are rounded down to 64bits, while this is not ideal, it is no where as damaging as the effect of truncating to 32 or 24 bit fixed point format. It is possible to design a noise shaper to retain more information at 64bits, but given there is no DAC that is capable of playing 64bits and also further processing (by other software) is not going to be able to make use of the additional precision, there is not much motivation to design  noise shapers for this purpose.

 

Thanks. I can understand that there is no DAC capable of playing 64-bits directly, but I'm not sure I understand why, if more information were retained at 64-bits, software such as HQPlayer could not benefit from that when noise shaping down to 24 bits for the DAC. My conversion specs in HQPlayer are: 768k/64f/2 -> 768k/24/2, and of course I use volume control (which is the whole purpose of taking all this trouble).

[Atriya]

Trying to A/B between 128-bit and 192-bit processing modes, I'm having flashbacks of A/B-ing between 128Kbps and 192Kbps MP3s, as a teenager two decades ago. Times have changed. :)

[Atriya]

Zaphod, is there a way to output 2 different formats for the same file, while sharing whatever part of the processing is common to them? For example, for each file, I would like to output a 64-bit version (for use when I want to use digital volume control) and a 24-bit version (when I do not). Just curious if a more efficient way is possible than repeating the whole processing, which is time consuming especially at 128/192-bits of resolution.

 

Also, what HF filtering would you recommend for DSD source files? 40Khz, or even less (50Khz/60Khz)?

[Atriya]

Bug report for the newly released version: for me at least (and I'm on the trial version), the convolution filter import gets stuck on yellow status, indefinitely saying that "this will take a minute". The convolution files I'm giving it are valid, and are used without issues by (for e.g.) HQPlayer.

[Atriya]

1 minute ago, Zaphod Beeblebrox said:

Email me the file you were trying to import and I will look into it.

 

The file is attached to this post. It's from AutoEQ.

[Atriya]

23 minutes ago, Zaphod Beeblebrox said:

Sorry for the double post, I noticed couple of errors that can cause confusion. Posting an update as I cannot edit my previous post. 

 

As a follow up to my previous post to help folks trying to figure out how much RAM they will need, here is a summary and a simple step by step guide (also attached is a pdf version).

The table helps in two use cases:

1. If you already have a PC/Mac and wish to find out the longest track, you could process.
2. If you wish to the acquire more RAM or a new PC/Mac

For use case 1: Say you have a 16GB of RAM and your DAC accepts a maximum of 352/368kHz PCM, then you can go to the second table (For 8fS DAC) and look at the Rows corresponding to 16GB RAM in both 64/128 and 256 bit precision sub-tables. You will see you can process tracks up to 12 minutes long on both Mac and Windows (green column). If you look under the pink column, you will also see 24 minutes listed, this is only if you only have a few tracks that are that long and are OK with longer processing times.

 

For use case 2: Say you have a R2R DAC that accepts 32fS input and you wish to remaster at 256 bit precision, go to 'For 32fS DAC' table and the '256 bit precision' sub table. Say you listen mostly to Jazz and Rock music and most of your tracks are within 10 minutes in length. Then you can look at the track length closest to 10 that is bigger or equal under the green column. The closest is 12 minutes, if you look at the corresponding RAM, you will see 64GB RAM would be a safe option to choose.

Bonus Example: As there are many with 16fS capable DACs, say you are like me and mostly listen to jazz and some chamber music and wish to remaster at 256 bits and most of your tracks are within 12 minutes in length. Then go to the 'For 16fS DACs' table, then to the '256 bit precision' sub-table. Look for '12' in the green column, then look for the corresponding RAM size for that row to the left, you will find you need 32GB of RAM.

 

Compare memory 256.pdf 85.19 kB · 1 download

 

This is very helpful, thanks. Would it be possible to augment this table for cases where the source is not PCM but DSD (64/128/256)?

[Atriya]

1 hour ago, Zaphod Beeblebrox said:

PGGB 256 Update (v5.0.44)

I just released an update for PGGB 256: v5.0.44

 

I was alerted to an issue by someone trying PGGB 256 on their MAC M1 with 16GB RAM. They were trying to process tracks longer than 12 minutes at 64 bit precision for a 4fS DAC (i.e., converting from CD rates to up to 192kHz) and experienced some gaps in remastered tracks. Going by the infographic I had shared (memory chart), for a 4fS DAC, one should be able to process tracks up to 24 minutes long at 256 bit precision on a PC/MAC with 16GB RAM.

 

I tracked down the issue to a compiler specific bug on Mac and have fixed it. This release addresses the issue and also as a bonus, is slightly faster on longer tracks.

 

Release notes:

Version 5.0.44: Infinity and beyond Edition (PGGB 256)
SQ Changes: None
Bug Fixes:
 * Fixed a bug caused some long tracks to be incomplete when processing at 64 bit precision on Mac
Features:
  * Performance improvement: 10% to 15% improvement in speed when processing long tracks.
  * Change in behavior for gain. Setting negative values will decrease the gain by that amount instead of fixing the peak at that gain.

Who should reprocess:

   *If you have been doing conversions on Mac using 64 bit precision with PGGB 256 and find some tracks have gaps or dropouts.

 

Upon upgrading to this version my output files (which are .wv: converted by PGGB itself) are completely empty, even though the processing takes the expected period of time (approx 30 minutes per track on my machine). I'm using EQ and a small negative manual gain setting.

 

[Atriya]

@Zaphod Beeblebrox I have a question about how gain works when using EQ. My EQ filter (from AutoEQ) has a "built-in" gain of about -2.5db. If I now apply a manual gain of say -1db, will the total gain be -3.5db? Or is that not how it works?

 

Asking because PGGBs output files with EQ seem to be louder than when using the same EQ filter (and same manual gain) in HQPlayer.

[Atriya]

I'm in the process of buying a Weiss DAC501-4ch, and wonder if there might be any merit to using PGGB with it.

 

While the DAC accepts 384Khz PCM and DSD128, it is perhaps unusual in that all incoming signals - both DSD and PCM - are internally converted to 195.312Khz PCM (yes, that strange number!) before being fed to ESS chips. Apparently Daniel Weiss determined that this is some kind of "sweet spot" for the chips.

 

The filter used internally cannot be changed, but I was able to find that it is a "conventional linear-phase filter with a symmetrical ringing before and after the single full-scale sample."

[Atriya]

42 minutes ago, Zaphod Beeblebrox said:

It may be worth trying 8fS @ 32 bits out of PGGB to see how it responds. It would benifit at best the same extent it benefits from DXD compared to Redbook.

 

I'll try it out. I wonder if it would make sense to try 4fs@32 bits, since 8fs will be converted down internally to approx. 4fs anyway.

[Atriya]

3 hours ago, Zaphod Beeblebrox said:

Since both are getting converted, you may as well provide it with better data as 8fS allows Noise shaping which can preserve more of the information, whereas at 4fS it is better to dither and you loose information in the audible range.

 

On this topic, I just noticed that PGGB compresses 8fs/32-bit to Wavpack. I believe FLAC added support for 32-bit recently? This is important for Roon users, since Roon doesn't support Wavpack.  

[Atriya]

4 hours ago, Zaphod Beeblebrox said:

Since both are getting converted, you may as well provide it with better data as 8fS allows Noise shaping which can preserve more of the information, whereas at 4fS it is better to dither and you loose information in the audible range.

 

Out of curiosity, wouldn't this always make it better for PGGB to upsample to 8fS (or higher), and then scale down to 4fS, if 4fS is the output? (Instead of directly upsampling to 4fS with dithering instead of NS, I mean.)

 

When fed 8fS files, the Weiss seems to be operating in two separate and sequential steps: first it downsamples to 4fS, then it "synchronizes" that 4fS signal to 195.3125 kHz. Could this be better than giving it 4fS directly?

[Atriya]

6 minutes ago, Zaphod Beeblebrox said:

Since  FLAC 1.4.0 , FLAC supports up to 16fS/32bits, does Roon support the latest FLAC?

Good question, perhaps it doesn't, but even if so I suppose it soon will.

[Atriya]

10 minutes ago, Zaphod Beeblebrox said:

There is only one way to find out, try both 4fS and 8fS and decide which you prefer. But I see your point, there is less processing involved on your DAC with 4fS. So try 8fS and also 4fS (both with NS ad dithering).

 

Empirically, the difference may well be imperceptible. Technically, I suppose it will come down to how good Daniel Weiss' POW-r family of proprietary dithering algorithms is (since I'm sure they are used in the 8fS -> 4fS conversion), something I am absolutely not qualified to determine.

[Atriya]

Deleted

[Atriya]

22 hours ago, Atriya said:

 

Empirically, the difference may well be imperceptible. Technically, I suppose it will come down to how good Daniel Weiss' POW-r family of proprietary dithering algorithms is (since I'm sure they are used in the 8fS -> 4fS conversion), something I am absolutely not qualified to determine.

 

Well, the difference is perceptible. I just got a 6/8 score on an ABX test between the original 1fS/16 PCM and 8fS/32 (PGGB at 256-bit processing) on the Weiss, and I can probably improve that score now that I'm more attuned to the differences.

 

The PGGBd version does sound better: slightly more "real", slightly better imaging perhaps, and there is just a tad bit more clarity (this is what I latched on to during the ABX, I think). On the other hand the 1fS might have a bit more "body", but now sounds ever so slightly muddy/veiled, compared to the PGGBd version.

 

The improvement is very subtle, but it's there, and it may not be subtle for speaker-users, or for better ears than mine. I only use headphones (Focal Utopias) and have realized that DAC/source differences are easier to pick out on speakers than on headphones.

 

Next stop is to compare DSD128 native vs. converted to 8fS/32-bit PCM by PGGB. (The Weiss doesn't do DSD256.)

[Atriya]

17 minutes ago, Zaphod Beeblebrox said:

You can use PGGB to convert DSD256.

 

Have tried comparing 4fS to 8fS done by PGGB?

 

Yes, but to keep the comparison fair it might be better to convert DSD128 and play the same DSD128 file natively on the Weiss (which can't play DSD256).

 

I haven't done the 4fS vs. 8fS comparison yet. When I do, would the best bet be 4fS using dithering or 4fS using NS? Of course, I can try both eventually; it's just time-consuming. It would be great to try 4fS NS first, unless there's a basic technical reason for NS to be inferior at 4fS.

[Atriya]

44 minutes ago, Atriya said:

 

Yes, but to keep the comparison fair it might be better to convert DSD128 and play the same DSD128 file natively on the Weiss (which can't play DSD256).

 

I haven't done the 4fS vs. 8fS comparison yet. When I do, would the best bet be 4fS using dithering or 4fS using NS? Of course, I can try both eventually; it's just time-consuming. It would be great to try 4fS NS first, unless there's a basic technical reason for NS to be inferior at 4fS.

 

I suppose it would depend on the NS algorithm you use. In HQPlayer for example, which has a choice of NS algorithms, the manual says that NS9 is optimized for 4fS rates, whereas LNS15 is only recommended for 8fS and especially 16fS.

[Atriya]

1 hour ago, Zaphod Beeblebrox said:

It is not about keeping comparison fair, DSD256 is not even an option unless you convert it to a rate the DAC 501 accepts IF you are interested in playing DSD256.

 

There is a reason the Noise shaping dropdown says 'Adaptive', I believe in 'less is more', rather than providing multiple choices, PGGB uses an adaptive NS individually optimized for the given sample rate (4fS, 8fS, 16fS, 32fS, 64fs) and also bit depths (16bits, 20 bits, 24bits, 32bits, 64bits etc.). The NS is not the same, it is adaptive based on your other choices, so all you do is decide if you want to use NS (even that when left in auto for less than 4fS will use dither) or use dither. Yes you should try the Ns first.

 

 

Update: I compared 1fS and 4fS+NS, and, once again, got a 6/8 on an A/B test. Subjectively, the 4fS seemed to have similar qualities as the 8fS.

 

I will edit this post with a 4fS vs. 8fS direct A/B.

 

EDIT: Inconclusive so far. The 4fS+NS seems identical to the 8fS to my ears. Maybe a tad more clarity on the 8fS, but I'd fail an A/B test.

[Atriya]

On 2/18/2023 at 9:21 PM, Atriya said:

 

Update: I compared 1fS and 4fS+NS, and, once again, got a 6/8 on an A/B test. Subjectively, the 4fS seemed to have similar qualities as the 8fS.

 

I will edit this post with a 4fS vs. 8fS direct A/B.

 

EDIT: Inconclusive so far. The 4fS+NS seems identical to the 8fS to my ears. Maybe a tad more clarity on the 8fS, but I'd fail an A/B test.

 

And finally, comparing PGGB's DSD to PCM conversion vs. the Weiss' native conversion: this comparison was harder to do because Foobar2000's ABX plugin doesn't support DSD, but going back and forth in Roon, I still found that extra tiny bit of clarity and realism with PGGB.

 

 

I chose to convert the DSD(128) to 4fS/32, because I reasoned that I was converting a fixed amount of information (in the DSD128 file) to PCM, and there was no point in converting to 8fS and then having the Weiss convert that to 4fS. In contrast, when upsampling 1fS PCM, PGGB would be creating information, and creating 8fS PCM would be creating more information than creating 4fS PCM, at least some of which might be retained by the Weiss' inescapable 8fS -> 4fS conversion. So I chose 8fS for that.