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

[Atriya]

9 hours ago, Atriya said:

 

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.  

 

 

In fact, close listening reveals that 8fS sounds slightly better then 4fS even when converting DSD. This is despite the fact that 8fS triggers an additional 8fS->4fS conversion stage inside the DAC. I don't know why it sounds better, but I suppose it comes down to the NS algorithm used by PGGB at 8fS vs. that at 4fS. Both are 32-bit.

[Atriya]

18 minutes ago, Zaphod Beeblebrox said:

Thanks for these comparisons, it will help others who may want to try the Weiss DAC 501. 

1. Were these done at 128bit or 256bit precision?
2. Would be interesting to see how the EQ implementation of 501 compares to using PGGB to EQ (if you plan to try it).

 

1. They are done at 256-bit precision.

2. Good question. At the moment the Weiss offers only 3 bands of parametric EQ. If one hijacks the 5 bands of Room EQ as a general parametric EQ (which is possible to do), that gives 8 bands, which is still less than the 10 bands that many headphone users who use published EQ settings (e.g. from oratory1990 or AutoEQ) need. Daniel Weiss informs me that they are considering adding more EQ bands in a firmware update. So far I haven't done any EQ comparisons, but I noticed that PGGB's EQ seems to be done before the NS phase. Whereas if I used the Weiss' EQ, it would obviously be after PGGB's NS phase. I wonder if that would make a fundamental difference.

[Atriya]

A question about EQ in PGGB: I know that PGGB needs convolutional filter .wav files, and doesn't work with a textual parametric EQ specification. What is the best workflow for those starting with a parametric EQ spec?

 

I know that Room EQ Wizard (REW) can be used to generate .wav filters from these, but is that the best/easiest way?

 

And if so, are there any specific settings in REW that should be kept in mind? I've been using the "Generic Equalizer", though I don't understand why it says "Generic Equalizer 96Khz".

[Atriya]

@Zaphod Beeblebrox is there any chance that PGGB will implement a headphone crossfeed? I sometimes use one, and it would be nice (and probably more accurate) to have it done in PGGB itself instead of after.

[Atriya]

18 minutes ago, Zaphod Beeblebrox said:

I will consider it for a future release if there is enough demand. Any specific implementation you are looking at?

ps: I remember you enquired at some point about multi-channel support. PGGB-IT! does that now.

I don't have a specific implementation is mind; flexibility is usually helpful.

 

Thanks for the tip on PGGB-IT! 

[Atriya]

On 2/20/2023 at 9:55 AM, Zaphod Beeblebrox said:

Yes, there is an advantage to using PGGB for EQ for two reasons:

1. The EQ is done post upsampling at a higher precision (128 or 256 depending on your setting) before NS, more than EQ being precise, it doesn't add any more noise due to quanitzation.
2. PGGB will auto scale as it is able to see the whole track, so you get higher headroom.

The advantage in using 501 is if you plan to use a different headphone or plan to use more than one preset, you do not have to process the files more than once.

 

It is still worth comparing to know if the compromises are worth it or not.

 

I got around to doing some very initial & preliminary subjective comparisons of PGGB's EQ with the Weiss DAC501-mk2's EQ.

 

Though Weiss' EQ has quite a reputation, I fully expected PGGB's to sound better, since it's done before noise shaping. Contrary to my expectations, preliminary critical listening finds PGGB's EQ sounding slightly harsher, with also possibly a little less depth in soundstage.

 

I'm comparing files upsampled to 32/384 at 256-bit precision with no EQ (but EQ enabled on the Weiss), to similar upsampling done with EQ (and EQ disabled on the Wiess). All PGGB settings are set to automatic.

 

[Atriya]

33 minutes ago, Zaphod Beeblebrox said:

There are a few variables here and Weiss is also an odd duck in the way the data is resampled too, so it is hard to extrapolate expectations based on how PGGB EQ works with other DACs. If you prefer Weiss EQ then that will have the advantage of simplifying your processing.

 

How did you match the EQ done via Weiss to the filters you imported within PGGB? also PGGB applies an auto gain on EQ to maximize headroom, so the levels will not be matched during your comparisons.  PGGB-EQ will be louder depending on the frequency content.

 

Indeed, I did not match levels in any principled way, but just "informally" by adjusting the volume by ear.

 

The filters used by PGGB were generated by REW, of course using the same EQ bands that the Weiss is set to use (8 bands in all).

[Atriya]

A quick tip & small feature suggestion to benefit Roon users: Roon does not support wavpack, not does it support FLAC 1.4, which supports 32-bit files unlike previous versions of FLAC.

 

However it does support ALAC, including playing back 32-bit ALAC files.

 

This is the only option then for storing 32-bit PGGB-d files in any format other than WAV, for playback in Roon.

 

The corresponding feature suggestion is to add ALAC compression. Of course, this is minor and can easily be done after PGGBing to WAV files.

[Atriya]

29 minutes ago, Zaphod Beeblebrox said:

It is time to hound Rooon to support FLAC 1.4 and also rates greater than 16fS. FLAC 1.4 support should be relatively easy and there is no good excuse not to support it. PGGB-IT! supports FLAC 1.4.

 

For Roon, even FLAC 1.4 support is a "feature" that needs to be requested and then upvoted by a large number of people in order to be considered for implementation. Needless to say, this is an absurd notion, but Roon doesn't care.

 

Here's the "feature suggestion":

 

FLAC 1.4.2 Support? - Feedback / Feature Suggestions - Roon Labs Community

 

You'll notice that the last (angry) comment is mine.

[Atriya]

I've been playing with surround virtualization, done using a VST3 plugin (Waves NX) applied in a DAW software (Reaper).

 

Would it be better to do this before or after PGGB?

 

If after PGGB, I assume having PGGB output 64-bit PCM would be best. Should noise shaping be set to "dither only"?

 

Interestingly the DAW doesn't dither or noise shape when the output is 32-bit PCM (which is my ESS DAC's input bitrate). It does give me the option of dithering or noise shaping for 24-bit PCM output. So that's another choice to make.

 

Yet another variable is EQ, which could be done either in PGGB or in the DAW. If in the DAW, it could be done before or after the surround virtualization.

[Atriya]

42 minutes ago, Zaphod Beeblebrox said:

Are you using head-tracking with Nx? In which case the only option is to do it after Nx, else it is preferable to do all the processing after Nx.

 

EQ with virtualization works differently than typical EQ, the EQ target you would need is a  'flat' EQ for headphones not a Harman like EQ. 

 

I'm not using the head tracker. In fact I switched from NX to GoodHertz CanOpener, which doesn't seem to make the kind of extreme changes to presentation that NX does.

 

Yes, I quickly realized that EQ-ing to Harman sounds awful with virtualization.

 

Thanks for the tip on EQ-ing to a flat response. I'm trying this now, after the NX/CanOpener processing. I exported from my DAW as a 64-bit floating-point file. PGGB is currently processing, but in my log I see the error:

 

[23-07-16 20:47:43] Start pass 2 [2]
[23-07-16 20:47:43] Error in function PGGB.UpdateProgress() at line 1346.

Error Message:
Invalid or deleted object.
While processing: <filename.wav>
[23-07-16 20:47:43] Error in function disp_file() at line 32.

Error Message:
Invalid or deleted object.
While processing: <filename.wav>
[23-07-16 20:47:43] Start pass 2 [2]

 

It didn't terminate the processing through.

 

UPDATE: Processing completed and sounds great! Not sure what that error was about...

 

[Atriya]

On 6/22/2023 at 6:14 PM, Atriya said:

 

I got around to doing some very initial & preliminary subjective comparisons of PGGB's EQ with the Weiss DAC501-mk2's EQ.

 

Though Weiss' EQ has quite a reputation, I fully expected PGGB's to sound better, since it's done before noise shaping. Contrary to my expectations, preliminary critical listening finds PGGB's EQ sounding slightly harsher, with also possibly a little less depth in soundstage.

 

I'm comparing files upsampled to 32/384 at 256-bit precision with no EQ (but EQ enabled on the Weiss), to similar upsampling done with EQ (and EQ disabled on the Wiess). All PGGB settings are set to automatic.

 

 

To follow up on this: something seems very off with PGGB's EQ, to my ears.

 

Some detective-work to hunt down the source of an inexplicable subtle flatness, harshness, and thinness of the midrange, revealed that even EQing with a flat impulse response (i.e., a flat EQ curve, not a flat target curve) seems to be the culprit (compared to PGGB with no EQ)!

 

(The files are pre-processed with Waves NX, but still, I assume EQ-ing anything with a flat EQ curve is supposed to have no effect at all.)

 

I have no idea what's wrong, or if I'm imagining it all. NS is set to Auto in both cases (EQ and no EQ) and in both cases seems to use:

 

[23-07-18 21:52:02] Start NS [1]
[23-07-18 21:52:02] Using dithered NS [1]
[23-07-18 21:52:03] Switching to NS Alternate [1]
[23-07-18 21:52:03] NS Corner: Fixed [1]

[Atriya]

On 7/19/2023 at 8:22 AM, Zaphod Beeblebrox said:

I have taken a different approach to what I was using previously with PGGB EQ. Previously, I was using a linear FIR filter, which is very transparent but comes with a huge computational cost and doubles the processing time. 

 

With PGGB 256 EQ, I have adopted a different approach which is based on Biquads,, think of them as Parametric EQ except an optimization algorithm automatically creates the filter to fit your input filter. I have not tested with a flat EQ (which may actually be the harder test case). 

 

I have not had much feedback (positive or negative) on the new EQ, so thanks for the feedback. In my own testing I have not heard ill effects with typical EQ, though I understand it can be system dependent. With EQ it is sometimes difficult to sperate the effect of EQ from other aspects of the presentation. I typically focus on the transients.

 

I plan to implement 10 band parametric EQ (first) and also FIR (later). Part of the reason is scientific to satisfy my own curiosity on the different approaches sound.

 

Thanks!

 

When trying to compare by ear, it doesn't help that the EQd version is nearly 3dB lower in volume than the non-EQd one, even when the gain is manually set to 0dB. (In fact, even when set to Auto, the PGGB .csv output shows gain as 0, despite the same ~3dB difference.)

 

Is there a way to match volume when EQing? The log shows:

 

[23-07-21 11:05:31] Pre Filter Gains: 0.94566, 0.94591 [1]
[23-07-21 11:05:31] Start EQ [1]
[23-07-21 11:05:31] Start, filter ch 1 [1]
[23-07-21 11:08:41] Done, filter ch 1 [1]
[23-07-21 11:08:41] Start, filter ch 1 [1]
[23-07-21 11:11:50] Done, filter ch 2 [1]
[23-07-21 11:11:51] Post Filter Gains: 0.72423, 0.71103 [1]

 

The .wav file is 384Khz to match my output sample rate, created using REW, and has a single 0.1db peak at 21Khz (yes, above the hearing threshold), just for testing purposes.

[Atriya]

8 hours ago, Atriya said:

 

Thanks!

 

When trying to compare by ear, it doesn't help that the EQd version is nearly 3dB lower in volume than the non-EQd one, even when the gain is manually set to 0dB. (In fact, even when set to Auto, the PGGB .csv output shows gain as 0, despite the same ~3dB difference.)

 

Is there a way to match volume when EQing? The log shows:

 

[23-07-21 11:05:31] Pre Filter Gains: 0.94566, 0.94591 [1]
[23-07-21 11:05:31] Start EQ [1]
[23-07-21 11:05:31] Start, filter ch 1 [1]
[23-07-21 11:08:41] Done, filter ch 1 [1]
[23-07-21 11:08:41] Start, filter ch 1 [1]
[23-07-21 11:11:50] Done, filter ch 2 [1]
[23-07-21 11:11:51] Post Filter Gains: 0.72423, 0.71103 [1]

 

The .wav file is 384Khz to match my output sample rate, created using REW, and has a single 0.1db peak at 21Khz (yes, above the hearing threshold), just for testing purposes.

 

An update. While I still haven't volume matched, my EQ "quality" problems seem gone just by clearing out the PGGB_EQ folder: the one containing the .pggbeq_bi files.

 

Although I was importing my EQ .wav before processing, it appears that a bug in PGGB was causing a totally different old EQ to be used instead of the one just imported, obviously resulting in a huge difference in sound from expected.

[Atriya]

@Zaphod Beeblebrox: almost certainly a newbie question, but I assume the PGGB EQ functionality is meant for EQ only, so attempting to import a HRIR (head-related impulse response) .wav file wouldn't work at all?

[Atriya]

@Zaphod Beeblebrox: With the latest version of PGGB, if I have "Increase LF fit" checked, then import a parametric filter (with linear phase enabled), and then click "Import Filter", the 'Increase LF Fit" check box automatically becomes unchecked. (The EQ status shows green, but if I check LF Fit now, it turns red again.)

 

Is this normal behavior, with a reason behind it?

 

My EQ frequencies are 1 Hz - 20 Khz. This is needed because I have a low cut filter at 20 Hz.

[Atriya]

@Zaphod Beeblebrox: Is it better to use noise shaping or "dither only" when the final result will undergo further sample rate conversion (in my case 384Khz->192Khz->195.312Khz) - but not other kinds of DSP - in the DAC?

[Atriya]

1 minute ago, Zaphod Beeblebrox said:

For 8fS output rate, yes I will recommend Noise shaping even if further conversions may happen later.

 

Okay! But not for 4fS?

[Atriya]

Will soon acquire a powerful machine with a 32-core CPU, and initially 64 GB but support for up to 2 TB (!!) of DDR5 RAM. This machine will have my PGGB license for sure. :)

[Atriya]

23 minutes ago, Zaphod Beeblebrox said:

Do share the build details too, as it may help others.

 

Here it is:

 

https://www.dell.com/en-us/shop/workstations-isv-certified/new-precision-7875-tower-workstation/spd/precision-t7875-workstation/xctopt7875mtus_vp?configurationid=3546e7d1-5d8d-4ced-9298-d591b527b3c7

[Atriya]

2 minutes ago, Zaphod Beeblebrox said:

What DAC are you using now?

 

Weiss DAC501-Mk2... which will stay for the foreseeable future...

 

I do 8fS/32-bit into the DAC, with noise shaping.

[Atriya]

4 minutes ago, kennyb123 said:

How much of an improvement does PGGB bring to that DAC?

 

A subtle but noticeable improvement in overall realism that I was able to successfully identify in A/B.

[Atriya]

@Zaphod Beeblebrox, have you ever considered making a PGGB license usable on 2 machines instead of just 1? For those of us with multiple machines but varying degrees of access to them, this would be a great convenience. It's not like my actual usage of PGGB would double - it would remain about the same - but it would provide some flexibility.

[Atriya]

Just now, Zaphod Beeblebrox said:

I am considering issuing a license through USB dongle to make this easier, no ETA yet.

 

Yes, that approach would be perfect!

[Atriya]

The upcoming PGGB DSD release is exciting! Unfortunately my main DAC (Weiss) doesn't do DSD natively, and neither does my Chord Mojo 2.

 

I wonder what a "cheap" NOS DAC to experiment with upsampled DSD1024 might be. The Holo Cyan 2 was recently released at $1200. Apparently Topping will release a 1-bit DAC in Q2 this year, called the D900.