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

[lpost]

I've read some of the material on XXHighend 'forum' and boy what a commitment to wrap ones head around it and get it setup and working. Haven't had the energy to try it.

 

Even the 'Getting started' posts are somewhat difficult to find and once there the list of articles to read is immense. I supposed after many years it becomes 2nd nature but I doubt the author will ever grow sales with this 1990s approach to information sharing.

 

It may be all slick now but I simply can't tell from what is presented.

[The Computer Audiophile]

Looks like Roon has issues with my 20 bit / 1,536 kHz PGGB content. 

 

[Zaphod Beeblebrox]

Yes, one more person had reported this to me. The files play fine on HQP but Roon seems to have a problem and we will have to report this to Roon. These are standard wav files, so no reason for them not to play.

[LowOrbit]

Roon advertise upto 768k support, so probably just being greedy there Chris!

[Zaphod Beeblebrox]

Roon was likely not expecting rates higher than that... If a bunch of us ask Roon, they may oblige

[ASRMichael]

@Zaphod Beeblebrox can I ask what is your back ground? 

[Zaphod Beeblebrox]

4 minutes ago, ASRMichael said:

@Zaphod Beeblebrox can I ask what is your back ground? 

Electrical Engineering/Applied Signal Processing - Machine Learning/Expert Systems/Audio

[taipan254]

For all those that have used PGGB in scale... How are you storing your large, remastered libraries? NAS? SSDs / HDs on your all-in-one server? NVME Storage on your all-in-one server? I would imagine the latter would be VERY expensive given file sizes, but the latter is also widely agreed upon here to be the best sounding storage option? Has something happened that has lowered the gap in quality between NVME and other storage methods that I'm not aware of? Or is the quality improvement from PGGB so large that the storage media and method doesn't really matter? 

[austinpop]

35 minutes ago, taipan254 said:

For all those that have used PGGB in scale... How are you storing your large, remastered libraries? NAS? SSDs / HDs on your all-in-one server? NVME Storage on your all-in-one server? I would imagine the latter would be VERY expensive given file sizes, but the latter is also widely agreed upon here to be the best sounding storage option? Has something happened that has lowered the gap in quality between NVME and other storage methods that I'm not aware of? Or is the quality improvement from PGGB so large that the storage media and method doesn't really matter? 

 

That's a good question, and serves as a reminder of several constraining factors of using this approach. PGGB is great, but does come with some baggage:

1. As already mentioned, you do need at least 32GB RAM, with 64GB or higher preferred, to process your music. Of course, this can be, and ideally should be, an unrelated machine to your music server/player.
2. The resulting files are very large. With 32/16FS files, the storage needed is about 15-20GB per album
3. Network streaming is not amenable to this approach, so for me as a DAVE user, I still rely on HQP sinc-L/LNS15 fed either from Roon or TAS (Taiko Audio Server). The latter's sound quality runs circles around Roon, but in discovery mode for new music, I can't deny the elegance of the Roon user experience.
4. For local playback, a network store like NAS isn't really a good option, as even with a 1Gbps home network, the load time for a 4GB file can be significant at a max read/write rate of 100-110 MB/s.

Now to your question. My entire local library of ~1600 albums at native sample rate occupies about 1.5TB. After PGGB conversion, this would need ~32TB. While Emile assures me that upgrading the NVMe SSDs in my Extreme will not negatively impact SQ, I am reluctant to do it due to the cost. I currently have 8TB. So I am approaching this as a sort-of jukebox, in the following way:

• Of the 1600 albums in my local storage, I only truly care about say half of it, or 800-1000 albums, so only these get the PGGB treatment preemptively.
• To store this content, about 16-20TB, I will use my NAS which already has adequate capacity. This will be my upsampled repository or warehouse.
• At any given point in time, I'll keep a subset of this repository on my music server, say 300 albums, or 6TB. This will be my jukebox.
• From time to time, I will rotate albums in and out, moving them to/from NAS (warehouse) to the server (jukebox).

I've toyed with the idea of using external USB storage, but am concerned about the SQ. Further, because of the size of these files, it really helps to have disk read speeds of 100s or even 1000s of MB/s, which NVMe drives do provide. A well implemented USB 3.2 SSD, with appropriately clean power with external PSUs might prove adequate, but this remains TBD in my setup.

 

[ray-dude]

My listening pattern has very much changed with PGGB.  I am back to my vinyl days.  I drop a PGGB album into the player, and disappear into it.  If I get a hankering for an album that I haven't processed, I drop it for processing into my PGGB machine, and by the time I finish with the album I'm listening to, it is ready to go

 

This is a wonderful way to take a random walk through my music collection, really listening to albums again.

 

I do keep copies of all my PGGB albums on my NAS as well.  If I don't have an album I want on my music server, just copy it over, and hit play.  Really loving this back to the future experience, like when I had my "active" 50 albums staged by the turntable, with the wall of albums off to the left, staging more albums out as the music took me there.

[kennyb123]

I have 8 TB of storage in my K30 and plan to fill it all with PGGB files.  I'm a little over half way there.  

 

I have successfully played PGGB files off my NAS via Roon/HQPlayer thought on a few files playback has paused on their own during playback.  An EtherRegen unfortunately slows the network coming into my K30 down to 100 mbps, so maybe without this bottleneck these files might play just fine.

 

Once I fill local storage I will likely to follow the jukebox approach described above by @austinpop.  I actually have a sync job set up that syncs all my PGGB files down to the K30.  I can easily enable/disable folders for sync.

[Account Closed]

3 hours ago, austinpop said:

 

That's a good question, and serves as a reminder of several constraining factors of using this approach. PGGB is great, but does come with some baggage:

1. As already mentioned, you do need at least 32GB RAM, with 64GB or higher preferred, to process your music. Of course, this can be, and ideally should be, an unrelated machine to your music server/player.
2. The resulting files are very large. With 32/16FS files, the storage needed is about 15-20GB per album
3. Network streaming is not amenable to this approach, so for me as a DAVE user, I still rely on HQP sinc-L/LNS15 fed either from Roon or TAS (Taiko Audio Server). The latter's sound quality runs circles around Roon, but in discovery mode for new music, I can't deny the elegance of the Roon user experience.
4. For local playback, a network store like NAS isn't really a good option, as even with a 1Gbps home network, the load time for a 4GB file can be significant at a max read/write rate of 100-110 MB/s.

Now to your question. My entire local library of ~1600 albums at native sample rate occupies about 1.5TB. After PGGB conversion, this would need ~32TB. While Emile assures me that upgrading the NVMe SSDs in my Extreme will not negatively impact SQ, I am reluctant to do it due to the cost. I currently have 8TB. So I am approaching this as a sort-of jukebox, in the following way:

• Of the 1600 albums in my local storage, I only truly care about say half of it, or 800-1000 albums, so only these get the PGGB treatment preemptively.
• To store this content, about 16-20TB, I will use my NAS which already has adequate capacity. This will be my upsampled repository or warehouse.
• At any given point in time, I'll keep a subset of this repository on my music server, say 300 albums, or 6TB. This will be my jukebox.
• From time to time, I will rotate albums in and out, moving them to/from NAS (warehouse) to the server (jukebox).

I've toyed with the idea of using external USB storage, but am concerned about the SQ. Further, because of the size of these files, it really helps to have disk read speeds of 100s or even 1000s of MB/s, which NVMe drives do provide. A well implemented USB 3.2 SSD, with appropriately clean power with external PSUs might prove adequate, but this remains TBD in my setup.

 

Rajiv with your background you should be able to setup a triple redundant CDN in your basement with a 40 Gbe fiber link to your listening room. Piece of cake. :)

[hols]

I am one of the early adopters of PGGB and I can share some of my experience here. And I don't have any financial dealings with PGGB other than a very happy user.

 

I have three DACs( Denafrips Terminator plus, Holo Audio May L2 and Chord Dave with Sean Jacobs DC4) in use on a rotation basis in my 3 different audio systems. Since Chord Dave has been talked about a lot in the earlier posts so I shall focus more on the Terminator+ and the Holo May which are both capable of going to 32fs (PCM 1411/1536).  I have in use 3 Linux servers(carrying my buddy's UKAS Debian OS) and also Taiko extreme server(Window10 OS).The Linux servers are loaded with HQplayer embedded and Taiko extreme with HQplayer 4 desktop and also TAS. I have been using HQplayer for more than 10 years and all along I have been favoring DSD over PCM(for its richer timbre and more musical feeling) until recently. In the past year or so using HQplayer DSD256 with ASDM7EC has been my first pick before the change. The change started after I have acquired the T+ and also the Holo May which are both capable of going to 32fs. Initially I have used HQplayer to real-time upsample to 32fs and using LNS15 noise shaping. The most striking change is there are a lot more details being heard. One can hear the details of different members in the orchestra so much so that it seems that one can now look at the leaves of different trees in the forest rather than just seeing the forest as a whole. The degree is so striking and it is so different from what is heard in 16fs. The only drawback is that it seems to be a little too pinpoint and a slight lack of bloom. But the musical sense is there. No doubt. And then comes the PGGB pre-upsampled 32fs files(using default settings) and all of a sudden the details of 32fs becomes so natural and the response of the orchestra is so unanimous yet you can hear the sounds of different members clearly and with good enough timbre. It seems that suddenly you can get to the best of both worlds. And that gave me the signal to go all the way for PCM. Now the PCM may still be a little more forward but the feeling are excellently conveyed. Everything is so fast so lively and so transparent. DSD would seem a little laid back and occasionally lacks liveliness.

 

The road actually is not that straight forward and there are quite some tweaks necessary before one can come to a nice ending.

 

First I must stress that one must do volume matching before you can appreciate the musical feeling of high resolution PCM. Given the quiet background of 32fs one can always turn the volume higher and more details can be heard without feeling sound becoming harsh and too pressing. In general I believe the limit of turning the volume higher is mid range becoming harsh. In 32fs one can tune up the volume by 3dB or so and still not feeling any strain from the sound. That is probably taking advantage of the quiet background.

 

Second point is I believe that at the source level more detail is the chief concern rather than getting a juicy sound. So to me 32fs is the key to get more detail. One can always tweak your subsequent components or cables to suit your own taste. Or one can also use the options in PGGB to suit your own taste. But if one do it the other way round I am not so sure that one can get back the detail off your juicy sound.

 

Third point is the concern of the native bit of the DAC. As has been elaborated in earlier posts that many DACs are quoted as 32 bits but actually they function best at 20 bits or so. So I converted several tracks to 32fs but separately with 19bit, 20bit, 21 bit, 22 bit, 23 bit, 24bit, 32bit, 64bit and compare them on the same system and see which bit gives the best for the DAC. For 19bit to 24bit I would use the default noise shaping of PGGB during the conversion but will not use the any noise shaping or filter of HQplayer. This is to avoid the double noise shaping which may degrade the sound. With 32 bit and 64 bit I will not use the default noise shaping of PGGB but use the LNS15 of HQplayer to reduce it to the conversion point of the DAC. Several observations come out from this test. First with increase in the bit from 19bit to 24bit there is progressively more detail coming out. I can hear more details in the piano both in microdetails as well as in timbre and in general a much more detailed and warm bass. The instruments in the lower bits file seems a little thinner than the larger bits ones and also lacking in detail. When it comes to 32 bit and 64 bit with LNS15 noise shaping there is initially a more welcomed warm sound with more sumptuous bass but on more critical listening it seems that it comes with a bit less details. An analogy would be like putting on a loudness button in the early HiFi equipment and the bass and treble are accentuated but the overall detail is downgraded. In both the Terminator+ and Holo May that I have tested I would choose 24 bit as giving the best SQ. This might be surprising to some because from some data it seems that 20 bit is the sweet spot. What I have reported above is my test result and I encourage that more tests be done to validate or refute the results.

 

Fourth point is one must try various sorts of files, classical music, vocals, bands or whatever because the results may vary. Good recordings and bad recordings will also come to different results. If the original recording is good then usually a good outcome is expected after PGGB.

 

The above is my personal experience of the PGGB and YMMV. I must thank ZB again for giving us such a great tool. It is really a game changer and is worth a try for everybody.

 

 

 

[MarkusBarkus]

Q: Is there a technical exchange that would be useful to the project and would further our understanding of the principles being explored for upsampling approaches?

 

Excerpted from @Miska's thread on HQPro:

 

If PGGB uses a billion tap filter, but doesn't make your song billion samples longer, it is doing it wrong and truncating your transients, making performance much worse than with shorter filters and thus more than making point of using longer filters moot.

 

I've said this before, but the whole thing with those very long filters is just silly and pointless. It just screws up your time domain completely. A billion poor taps cannot beat thousand good ones.

 

For me, the interesting thing is to make filter as short as possible while still having as perfect frequency domain performance as possible. IOW, making filter kind of short and long simultaneously, getting as close as possible to the mathematically impossible - at the sweet spot in the middle. So reaching goals of both MQA and Chord (totally opposite), but better in both respects.

 

 

[Zaphod Beeblebrox]

1 hour ago, MarkusBarkus said:

Q: Is there a technical exchange that would be useful to the project and would further our understanding of the principles being explored for upsampling approaches?

 

Excerpted from @Miska's thread on HQPro:

 

 

If PGGB uses a billion tap filter, but doesn't make your song billion samples longer, it is doing it wrong and truncating your transients, making performance much worse than with shorter filters and thus more than making point of using longer filters moot.

 

I've said this before, but the whole thing with those very long filters is just silly and pointless. It just screws up your time domain completely. A billion poor taps cannot beat thousand good ones.

 

For me, the interesting thing is to make filter as short as possible while still having as perfect frequency domain performance as possible. IOW, making filter kind of short and long simultaneously, getting as close as possible to the mathematically impossible - at the sweet spot in the middle. So reaching goals of both MQA and Chord (totally opposite), but better in both respects.

 

 

As many have mentioned here before PGGB is meant to be complementary not competitive to HQP. I use HQP for playback too. I have no interest in creating short filters as HQP already does a great job of that. 

 

PGGB started as an experiment to see if there are any gains to be made with longer filters and to find how long is too long, and the only reason it exist today is because collectively we felt the experiments were a success, i.e., there were audible benefits to this approach of using long filters.  I understand there are certain expectations based on math, and then there is the subjective results of what we hear. I do not claim PGGB to be a panacea  to audio nirvana that satisfies everyone and every system.

 

PGGB's 'claim to fame' may be 'billions of taps', it is a hyperbole in some ways. PGGB will use only as much as needed but can be limited to whatever you say you want. So it is easy enough for anyone to test it with 1M, 2M, 4M taps etc. Feel free to experiment with it yourself and draw your own conclusions.

 

 

 

Another question we had during PGGB development was, should we treat a whole album as a single long track or should we process each track individually. There are pros and cons of both approaches. When treating a whole album as a single track, the inherent assumption is the tracks do not have any discontinuity , i.e they are on single continuous recording that was later split into tracks, which is rarely the case except for some orchestral works. On the other hand processing each track individually with very long filter would mean not all taps were used for reconstruction of all samples. Does this negatively impact sound? or does it still improve over the original track? 

 

Again, this experiment too is possible in PGGB. It is possible to force PGGB to combine any number of tracks in the album, then choose the number of taps you wish to use. PGGB will process all the tracks in a gapless fashion, then split them and assign the metadata so that they still retain the track numbers and track names. More information about this can be found here and here.

 

PGGB has a bunch of knobs and hidden features that were used for experiments,  most of them are hidden so that it does not overwhelm anyone, and what is presented as a default is what the majority of beta testers preferred (about 35 including me). 

 

Everyone's preferences are different,  that is what makes this hobby both fun and challenging, which is why it is best to listen and make your own decisions and I will be happy to help if you need.

 

 

[ted_b]

4 hours ago, hols said:

In both the Terminator+ and Holo May that I have tested I would choose 24 bit as giving the best SQ. This might be surprising to some because from some data it seems that 20 bit is the sweet spot. What I have reported above is my test result and I encourage that more tests be done to validate or refute the results.

Hols,

Nice to hear from you.  I am specifically asking about the May as dac.  When you say "I would choose 24 bits" do you mean in PGGB, HQPlayer, or both?  If just HQPlayer then are we led to believe you are choosing 32 or 64 in PGGB, and doing the LS15 noise shaping in HQP?  And default settings for PGGB (except noise shaping)?

 

Also, are you converting all your DSD to PGGB-PCM, or staying in DSD and processing them with HQP....I couldn't tell from your comments, although you said you liked PCM better now.

Thx

Ted

[austinpop]

2 hours ago, ted_b said:

Hols,

Nice to hear from you.  I am specifically asking about the May as dac.  When you say "I would choose 24 bits" do you mean in PGGB, HQPlayer, or both?  If just HQPlayer then are we led to believe you are choosing 32 or 64 in PGGB, and doing the LS15 noise shaping in HQP?  And default settings for PGGB (except noise shaping)?

 

Ted, 

 

Due to the time difference with Hong Kong, and since I'm aware of @hols experiments, I think the three scenarios he describes are as below. Obviously, this is provisional until he confirms.

 

24-bit

 

native file ---------> PGGB ----------> upsampled file -----> HQP ----------> DAC

                                    out = 32fs                                            filter = None

                                    output bits = 24                                  DAC bits = 24

                                    NS = Auto (On)                                   dither = None

 

32-bit

 

native file ---------> PGGB ----------> upsampled file -----> HQP ----------> DAC

                                    out = 32fs                                            filter = None

                                    output bits = 32                                  DAC bits = 24

                                    NS = Off                                              dither = LNS15

 

64-bit

 

native file ---------> PGGB ----------> upsampled file -----> HQP ----------> DAC

                                    out = 32fs                                            filter = None

                                    output bits = 64                                  DAC bits = 24

                                    NS = Off                                              dither = LNS15

[hols]

2 hours ago, ted_b said:

Hols,

Nice to hear from you.  I am specifically asking about the May as dac.  When you say "I would choose 24 bits" do you mean in PGGB, HQPlayer, or both?  If just HQPlayer then are we led to believe you are choosing 32 or 64 in PGGB, and doing the LS15 noise shaping in HQP?  And default settings for PGGB (except noise shaping)?

 

Also, are you converting all your DSD to PGGB-PCM, or staying in DSD and processing them with HQP....I couldn't tell from your comments, although you said you liked PCM better now.

Thx

Ted

Hi Ted,

Sorry that I did not make it clear in my post. I made several PGGB files using the default setting which is highlighted grey in the Manual (that is natural transparency, transparent presentation and moderate HF noise filter) and then I vary the output bit depth to 19 bit, next one is 20 bit etc up to 24 bits in separate folders. For 19 bits to 24 bits I would use the default adaptive noise shaping. This noise shaping is meant to clean up the frequency repetitions.  Then when I feed a 19 bit file to the HQplayer the HQplayer setting is also changed to 19 bits and no filter and no more noise shaping is used in HQplayer. When I make a 32 bit or 64 bit PGGB file I would not use the adaptive noise shaping of PGGB because I need to put the HQplayer setting to 32 bit and also use the LNS15 noise shaping in HQplayer. This is based on the understanding that with 32 bit there will be some manupulation by the DAC anyway so using the PGGB noise shaping may end up in double noise shaping. 

My statement of I would choose 24 bits simply means that I think 24 bits give the best SQ. And then when I make PGGB files I would use 24 bit and also use adaptive noise shaping of PGGB and then in HQplayer I wouls set it to 24 bit and no filter or noise shaping. I don't do streaming with Tidal or Quobuz because I have got already too many albums so the default setting in HQplayer would be set to 24 bits.

 

I have tried some conversion of DSD to PCM the result is variable. It depends on whether the original DSD file is well recorded or not. We all know that some DSD files are not really good recordings or true high resolution recordings. My intention is to use a similar strategy like Rajiv's jukebox  method. This is because I have over 15K albums ripped into 10Tb in my NAS and it is impossible to convert them all to PGGB files as it will end up to almost 200Tb. And it will take 3 years to do it.  So I would only pick the ones that I think has high chance to get benefit. But it may be tricky as to how to pick so this will have to be modified along the way. 

[ted_b]

Deleted.  My bad.

[ted_b]

5 minutes ago, hols said:

My statement of I would choose 24 bits simply means that I think 24 bits give the best SQ. And then when I make PGGB files I would use 24 bit and also use adaptive noise shaping of PGGB and then in HQplayer I wouls set it to 24 bit and no filter or noise shaping.

So this is the May setup, thanks.  This prompts the question:  since HQPlayer is now doing no DSP (other than providing 24 bit output) have you tried these 24 bit PGGB files on other players?  Or is HQPlayer the choice also due to DSD playback (where you may not PGGB the files)?

[austinpop]

Turns out HQPlayer, in pass-through mode, is an excellent PCM music player, far better-sounding than Roon.

 

Too bad there isn’t a PCM Direct flag, but you can achieve the same with settings.

[ted_b]

Yes, it is.  I even heard that with your sample files you sent me.  Oh, and Roon seems to have issues with 32fs files too, even as an HQP-front end.

[Miska]

Sending 32 bit to Holo Audio DACs will just result in last 8 bits being truncated (thrown away). The USB interface even reports that it is 24-bit in 32-bit sample container. HQPlayer can auto-detect this on Linux too. But 20-bit recommendation combined with NS5, NS9 or LNS15 noise shaper is based on measurements. Sending 24-bits there will just significantly increase distortion of especially low level signals and linearisation effect of noise shaper designed for this purpose is just lost because the conversion ladder doesn't have enough precision.

 

Correct way to come up with number of DAC bits is to measure the DAC's analog output. (I have a reason why I have invested tens of thousands of Euros on measurement gear)

 

[Johnseye]

16 minutes ago, Miska said:

Sending 32 bit to Holo Audio DACs will just result in last 8 bits being truncated (thrown away). The USB interface even reports that it is 24-bit in 32-bit sample container. HQPlayer can auto-detect this on Linux too. But 20-bit recommendation combined with NS5, NS9 or LNS15 noise shaper is based on measurements. Sending 24-bits there will just significantly increase distortion of especially low level signals and linearisation effect of noise shaper designed for this purpose is just lost because the conversion ladder doesn't have enough precision.

 

Correct way to come up with number of DAC bits is to measure the DAC's analog output. (I have a reason why I have invested tens of thousands of Euros on measurement gear)

 

 

If the 20 bit recommendation was based on measurements with NS9 or LNS15 then could it be different for PGGB?

 

There is a difference in sound that @hols is experiencing.  I suppose it's possible Hols likes the sound of some distortion.  I don't mean that in a negative way because a lot of what characterizes the sound of something, can be some form of distortion.

[Zaphod Beeblebrox]

59 minutes ago, Johnseye said:

If the 20 bit recommendation was based on measurements with NS9 or LNS15 then could it be different for PGGB?

 

There is a difference in sound that @hols is experiencing.  I suppose it's possible Hols likes the sound of some distortion.  I don't mean that in a negative way because a lot of what characterizes the sound of something, can be some form of distortion.

My recommendation for the use of 20 bits was based on linearity measurements made by Stereophile and ASR and those measurements are not with any form of noise shaping.  

 

Using lesser bits leads to more quantization error, so when recommending 19 bits or 20 bits for a 24 bit DAC, what is happening is the last 4 or 5 bits are zeroed out and not being used to avoid any distortions they may introduce. To deal with the higher quantization error (because now we have fewer levels to represent the signal), noise shaping is done. Noise shaping is a signal  processing trick that just pushes out the quantization errors outside of the audible range, so in the audible range, it would sound as though the bit depth was much higher (depending on how good the noise shaper is). End result being better signal accuracy and lower noise floor in the audible range.

Throughout  the development of PGGB, I have kept an open mind to what someone hears even if it does not tally with my expectation and it could be due to a variety of reasons. It could be personal preference, the playback chain etc., and if it sounds right to someone, then that is what matters. I feel PGGB is a means to an end, the end being enjoying the music. PGGB can be tuned to suit ones listening preferences and the default settings and recommendations are just that;  hints on where to start, the fun is in the discovery of what you like. PGGB also has a 'wizard robot'  to aid in this discovery process: PGGB - Onboarding (remastero.com)