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

[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.

[Zaphod Beeblebrox]

1 hour ago, Atriya said:

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.

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

[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.

[austinpop]

10 hours ago, Zaphod Beeblebrox said:

There have been numerous requests to improve memory performance of PGGB, especially to allow high precision computing without the need to invest in a lot of RAM or in Server grade hardware. We have been working on addressing this while improving on the algorithms too. Many thanks to those who have been patiently waiting and many thanks to the beta testers for their feedback and encouragement, we have been working on this for the past 9 months and constantly improving. There was even an intermediate version (v4) which we skipped over to bring v5.

 

PGGB 256 Infinity and Beyond Edition

I am happy to announce PGGB 256 v5.0.42. PGGB-AP is now PGGB 256. PGGB 256 uses completely revamped algorithms, but still follows the same fundamental principle of getting as close to perfect reconstruction as possible. The new algorithms are optimized to maximize reconstruction accuracy to near theoretical limits, and it improves over what PGGB-AP did.

• PGGB 256 uses highly optimized custom built multi precision math libraries. PGGB 256 is now faster and more memory efficient than ever before.
• PGGB 256 uses a minimum of 128bit precision for resampling (even for 64bit processing), one can optionally use up to 256bit precision for all of the processing.
• The configuration menu is much simplified and there is an automatic mode that now chooses the optimal settings based on each track. More details can be found here.
• PGGB 256 does away with having to choose taps, does not use windowed sinc function and is non-apodizing.
• PGGB 256 now has a 'XDMS Mode' under the hidden menu to split output files into 1.25GB parts to aid play back in Taiko Audio's XDMS.
• PGGB 256 now supports 64bit output that is noise shaped, this is useful if you wish to process these tracks further.

 

Licensing options have changed

There are now three types of licensing in addition to the free trial. More information can be found here.

1. Trial licenses: They have been simplified, PGGB 256 will automatically start in trial mode and one need not request a trial license separately. As before it limits processing to 5 tracks at a time for 64 bits and 2 tracks at a time at 128 or 256 bits.
2. Perpetual (64): Existing PGGB-AP perpetual license holders are automatically upgraded to 'Perpetual (64)' license for PGGB 256.
   1. You can run previous version (v3 or older) side by side with PGGB 256.
   2. PGGB 256 will run without any limitations when set to 64bit processing. Even when set at 64bit processing the resampling is done at 128bits and one also gets the full benefits of the new revamped algorithms.
   3. When set to 128 or 256bit, processing is limited to 2 tracks at a time (one can restart to process couple of tracks again)
3. Perpetual (256): This allows end-to-end processing at 256 bits without any limitations.
4. Upgrade to (256): Existing PGGB-AP perpetual license holders or 'Perpetual (64)' license holders can upgrade to 'Perpetual (256)' license.

Where is my cheese

If you have been using PGGB-AP, PGGB 256 uses a different configuration file for settings. This allows PGGB 256 to coexists with previous versions. It also means, you have to setup PGGB 256 again with your default settings (which it will remember going forward).
Some of the previous settings are no longer available as they are not relevant:

1. Most notably, no more taps: PGGB 256 does away with the concept of taps. The new algorithms do not limit the quality of output based on the available resources, it uses an adaptive processing pipeline to achieve the same reconstruction quality with the available resources*. 
2. Transparency and presentation options are gone: With windowed sinc function, there is always a choicebetween time domain and frequency domain performance, and these controls provided the parameters to tweak windowing. PGGB 256 does not use windowed sinc functions and these compromises are no longer needed.
3. Apodizing check box: The check box is gone as PGGB 256 is non apodizing.
4. Hidden menu option DSD throttling: This option is no longer needed and if TDP is an issue, it can be controlled by setting the number of workers.
5. Hidden menu option Disk Caching: This option is gone because PGGB 256 is a lot more memory efficient. 

*PGGB 256 still needs enough memory available to hold input and output buffers at the desired precision, the processing however is designed to trade speed to fit into memory. The required memory proportional to the length of the track.

 

Having been involved closely with ZB in his creation of PGGB, I know how much it has evolved and improved with each iteration. As existing PGGB users know, PGGB-AP at 192-bit resolution was a major step forward in improving SQ over the original PGGB at 64-bit precision.  Yet, I consider PGGB-256 to be an even more significant upgrade than PGGB-AP.  Some of you may be old enough to remember the old Miller Lite commercial: "Tastes Great. Less Filling." With PGGB-256, it's more a case of "Tastes better. Less filling!" PGGB-256 gives you: 

• another dramatic uptick in sound quality, but equally importantly,
• a dramatic improvement in performance, where even the most pathological tracks can process comfortably on a consumer desktop.

I've already described my SQ impressions of PGGB up-thread, so I won't repeat myself again. PGGB-256 just gives you more of the goodness: coherency, transparency, density, soundstage size, and layering. Rather than going on my or anyone else's descriptions, the best thing would be to give it a try on your favorite tracks, and see what you think.

 

For existing users, even if you don't upgrade to the p256 license, you'll definitely hear a substantial uptick in SQ. Should you upgrade to 256-bit? Try a few tracks and have a listen. What I can tell you is that for me, it was a no brainer, and I sent in my upgrade fee (yes -- I paid the same fee as everyone else) immediately. It also says something that as far as I know, every single one of ZB's beta testers opted to upgrade as well. The benefits, once heard, are hard to unhear. Such is audiophila!

 

A final word on performance. It is rare when a hobby intersects with one's professional life. In my case, performance engineering is my profession, so helping ZB tune the performance of PGGB-256 (and earlier versions) was satisfying in a different way than work projects. I'll admit it sometimes felt surreal to be analyzing PGGB CPU/memory/disk profiles, knowing that this was helping my enjoyment of music. A very rewarding experience!

[Gavin1977]

Great work...  I'll be trying it!

[kennyb123]

8 hours ago, austinpop said:

• another dramatic uptick in sound quality, but equally importantly,
• a dramatic improvement in performance, where even the most pathological tracks can process comfortably on a consumer desktop.

This is spot on.
 

I had been super-impressed with the sound quality of the last version at higher precisions.  My Mac with 128 GB was able to process a good amount of my music at P192, but it was slow and it really struggled with longer tracks.  Also, the highest precision I could get from DSD was P128.  I found myself at the time thinking that I needed to throw a lot more money at hardware.  
 

Foolish me.

 

I sit here today having pretty much reprocessed everythingI processed with v3 but did it all in a fraction of the time at 256 bit arbitrary precision.  That’s crazy!  At no point did it seem as though my Macs were even breaking a sweat.  Memory utilization remained below 50% and there was nothing in my music library that PGGB 256 couldn’t process at 256 bit precision.  It even successfully processed a DSD256 album that I recently purchased.

 

Impressive stuff, eh?  Well that’s nothing compared to the gains in sound quality.  @Zaphod Beeblebroxhad mentioned that he had been targeting both improved reconstruction accuracy and reduced noise.  Don’t ask me how - but my ears tell me that this is exactly what he achieved.  @austinpopabove mentioned “coherency, transparency, density, soundstage size, and layering” and I most certainly hear all that.  I’d add to it purity, realism and aliveness. 

 

8 hours ago, austinpop said:

I'll admit it sometimes felt surreal to be analyzing PGGB CPU/memory/disk profiles, knowing that this was helping my enjoyment of music. A very rewarding experience!

We owe a huge thanks to you as well for your efforts to assist ZB.  I’m glad you enjoyed it.

[LowOrbit]

Golly - I've been waiting for this, checking in frequently to see if ZB had dropped the announcement here.

 

And I wake up in a HIlton on a freezing Hew Hampshire morning, jetlagged and 3000 miles from my desktop machine reserved for processing my PGGB files - and here it is.

 

It'll make the redeye flight back to the UK Friday much more bearable.

 

I don't see how I will not be upgrading, so thanks in advance ZB and the testing team.

[taipan254]

I just posted the below on Head-Fi's Gustard X26-Pro thread and I thought I'd share it here since it relates directly to PGGB-RT. 

 

All the best!

 

------------------------------------------------------------------------------------------------

 

PhazeCrive said:

I tried looking into HQ player and PGGB but these upscalers are so unnavigable I'd rather just buy something like an M Scaler so I have the freedom to use my own player...(groove music lol) unless there's another way to play and search my files without opening them from HQplayer? I'd love that but I'm not sure how. It won't even open up root folders of which I have all my music organized into subfolders, so that's a killer. For reference I only listen to FLACs I have downloaded or ripped.

Earlier today, it dawned on me that Foobar2000 may be an option for me, you, and others that want to sample PGGB. There is a "component" / "add-on" to Foobar2000 called PGGB-RT. It is limited in a number of ways compared to PGGB 256 (the offline remastering tool). However, it does allow one to get 64-bit processing of 2bn taps of PGGB for free (1bn better than HQPlayer's Sinc-M filter) and 90 seconds per track of free PGGB at up to 1bn taps (depending on track length).

Today, I added the PGGB-RT component from the Foobar component library. Since I have a streamer, I also downloaded the UPnP Media Renderer output component as well. I then set my ultraRendu streamer on MPD / DLNA mode. Next, I played a few songs with native Gustard filters (i.e., PGGP-RT was INACTIVE) to acclimatize to Foobar. Lastly, I played the same music through Roon via HQP and NAA with no upsampling (no filters, no dither, straight pass-through). This is where I came to conclusion one:
 

WITHOUT ANY UPSAMPLING, I have to say that Foobar2000, for me, sounds a lot better streaming to my ultraRendu via UPnP than Roon streaming to HQP via NAA. I previously came to the conclusion that Roon streaming to HQP via NAA was better than Roon streaming to RoonBridge via RAAT. I'm bad with audiophile jargon but again I come back to "clarity" / "lack of fuzziness". Foobar2000 + UPnP sounds the "cleanest" to me.

I then went back to Foobar2000. I selected the same music and right clicked resample with PGGB. I also turned on NOS-Mode on the Gustard. I then played all the tracks, and then went back to Roon with HQP via NAA with Sinc-M and LNS15 filters enabled. I did this with a few times with different taps selected in PGGB-RT's settings in Foobar (controlled in the settings tab). I came to conclusion two:
 

EVEN WITH 1 MILLION TAPS, I have to say that Foobar2000 + PGGB-RT streamed to my ultraRendu via UPnP sounds a lot better than Roon + HQP streamed to my ultraRendu via NAA. Further, with more taps, the more I perceived "reverb" / "texture" of guitars (say the guitar heavy opening of Radiohead's "The Bends") and "decay" / "space" (say the symbols at the start of Danzig's "Last Ride"). The improvements increased as taps increased, albeit at a smaller and smaller scale for each incremental increase in taps. 

Caveats:

1. My laptop sucks: 8 Gigs of RAM, Quadcore Mobile i7855U CPU... My laptop was unable to multitask even with 1mn taps, and the delay to start a new track was substantial. There were also lots of dropouts, especially as the number of taps increased. I would bet a powerful desktop with lots of RAM (32GB) would sound much better and upsample with PGGB-RT much quicker. I also think this explains the diminishing returns I heard with increased taps.
2. My headphones are not "top-tier"... again, I use ThieAudio Oracle Mk1s and a DCA x Drop Aeon Open Back in balanced mode. What has enabled me to perceive differences in upsampling has been the acquisition of an ultraRendu streamer and some power hacks (mains filter, new cheapo audiophile fuses, and ground boxes). However, I definitely think my headphones are also holding me back.
3. Different software configurations sound different. I conducted this comparison in the above manner to control for SQ differences in different software music players. I think it is fairly well-known on other forums (AudiophileStyle, What's Best Forum) that, with respect to sound quality, Roon leaves a lot to be desired relative to lighter-weight players (I personally can confirm Foobar2000 and Audirvana sound better than Roon, and many say Taiko's native player bests everything else on the market, though I have not heard it). I don't know if folks here on head-fi have the same opinion.
4. None of this, except for HQP, works with streaming. The only million+ tap solution for streaming services like Qobuz right now is sadly via HQPlayer. It's better than nothing, but for streaming-centric PCM-based upscalers, having one option sucks.... Maybe PGGB comes up with something better than HQP for real-time playing that is also Roon and end-point compatible. Maybe a higher bit, lower tap real-time processing engine (or a lower bit, higher tap real-time processing engine)! Something far less resource-intensive but sounds better than HQP for PCM upscaling. That seems like smart R&D if I was @Zaphod Beeblebrox. HQP is DSD-focused anyways! PCM upscaling is an afterthought for HQP.
5. All systems are different, as is perception and hearing.

In any case, going back to Roon with HQP and NAA was a "Let Down" (pardon the intended Radiohead pun). I can't stand drop-outs / skipping and I simply cannot multitask with Foobar while PGGB-RT is enabled. Time to build a hefty CPU for processing. I think this Gustard x26 Pro is far more capable than I'm realizing. I'm definitely not getting the most out of it. But I am getting more out of it.
 

[Zaphod Beeblebrox]

7 hours ago, taipan254 said:

I just posted the below on Head-Fi's Gustard X26-Pro thread and I thought I'd share it here since it relates directly to PGGB-RT. 

 

All the best!

 

------------------------------------------------------------------------------------------------

 

PhazeCrive said:

I tried looking into HQ player and PGGB but these upscalers are so unnavigable I'd rather just buy something like an M Scaler so I have the freedom to use my own player...(groove music lol) unless there's another way to play and search my files without opening them from HQplayer? I'd love that but I'm not sure how. It won't even open up root folders of which I have all my music organized into subfolders, so that's a killer. For reference I only listen to FLACs I have downloaded or ripped.

Earlier today, it dawned on me that Foobar2000 may be an option for me, you, and others that want to sample PGGB. There is a "component" / "add-on" to Foobar2000 called PGGB-RT. It is limited in a number of ways compared to PGGB 256 (the offline remastering tool). However, it does allow one to get 64-bit processing of 2bn taps of PGGB for free (1bn better than HQPlayer's Sinc-M filter) and 90 seconds per track of free PGGB at up to 1bn taps (depending on track length).

Today, I added the PGGB-RT component from the Foobar component library. Since I have a streamer, I also downloaded the UPnP Media Renderer output component as well. I then set my ultraRendu streamer on MPD / DLNA mode. Next, I played a few songs with native Gustard filters (i.e., PGGP-RT was INACTIVE) to acclimatize to Foobar. Lastly, I played the same music through Roon via HQP and NAA with no upsampling (no filters, no dither, straight pass-through). This is where I came to conclusion one:
 

WITHOUT ANY UPSAMPLING, I have to say that Foobar2000, for me, sounds a lot better streaming to my ultraRendu via UPnP than Roon streaming to HQP via NAA. I previously came to the conclusion that Roon streaming to HQP via NAA was better than Roon streaming to RoonBridge via RAAT. I'm bad with audiophile jargon but again I come back to "clarity" / "lack of fuzziness". Foobar2000 + UPnP sounds the "cleanest" to me.

 

I then went back to Foobar2000. I selected the same music and right clicked resample with PGGB. I also turned on NOS-Mode on the Gustard. I then played all the tracks, and then went back to Roon with HQP via NAA with Sinc-M and LNS15 filters enabled. I did this with a few times with different taps selected in PGGB-RT's settings in Foobar (controlled in the settings tab). I came to conclusion two:
 

EVEN WITH 1 MILLION TAPS, I have to say that Foobar2000 + PGGB-RT streamed to my ultraRendu via UPnP sounds a lot better than Roon + HQP streamed to my ultraRendu via NAA. Further, with more taps, the more I perceived "reverb" / "texture" of guitars (say the guitar heavy opening of Radiohead's "The Bends") and "decay" / "space" (say the symbols at the start of Danzig's "Last Ride"). The improvements increased as taps increased, albeit at a smaller and smaller scale for each incremental increase in taps. 

 

Caveats:

1. My laptop sucks: 8 Gigs of RAM, Quadcore Mobile i7855U CPU... My laptop was unable to multitask even with 1mn taps, and the delay to start a new track was substantial. There were also lots of dropouts, especially as the number of taps increased. I would bet a powerful desktop with lots of RAM (32GB) would sound much better and upsample with PGGB-RT much quicker. I also think this explains the diminishing returns I heard with increased taps.
2. My headphones are not "top-tier"... again, I use ThieAudio Oracle Mk1s and a DCA x Drop Aeon Open Back in balanced mode. What has enabled me to perceive differences in upsampling has been the acquisition of an ultraRendu streamer and some power hacks (mains filter, new cheapo audiophile fuses, and ground boxes). However, I definitely think my headphones are also holding me back.
3. Different software configurations sound different. I conducted this comparison in the above manner to control for SQ differences in different software music players. I think it is fairly well-known on other forums (AudiophileStyle, What's Best Forum) that, with respect to sound quality, Roon leaves a lot to be desired relative to lighter-weight players (I personally can confirm Foobar2000 and Audirvana sound better than Roon, and many say Taiko's native player bests everything else on the market, though I have not heard it). I don't know if folks here on head-fi have the same opinion.
4. None of this, except for HQP, works with streaming. The only million+ tap solution for streaming services like Qobuz right now is sadly via HQPlayer. It's better than nothing, but for streaming-centric PCM-based upscalers, having one option sucks.... Maybe PGGB comes up with something better than HQP for real-time playing that is also Roon and end-point compatible. Maybe a higher bit, lower tap real-time processing engine (or a lower bit, higher tap real-time processing engine)! Something far less resource-intensive but sounds better than HQP for PCM upscaling. That seems like smart R&D if I was @Zaphod Beeblebrox. HQP is DSD-focused anyways! PCM upscaling is an afterthought for HQP.
5. All systems are different, as is perception and hearing.

In any case, going back to Roon with HQP and NAA was a "Let Down" (pardon the intended Radiohead pun). I can't stand drop-outs / skipping and I simply cannot multitask with Foobar while PGGB-RT is enabled. Time to build a hefty CPU for processing. I think this Gustard x26 Pro is far more capable than I'm realizing. I'm definitely not getting the most out of it. But I am getting more out of it.
 

Thanks for the feedback.  The new 64 bit Foobar would simplify things a bit and improve stability (once foo-RT is updated). I plan to update it with the newer algorithms of PGGB v5. There is no concept of taps anymore, for RT with the new PGGB algorithms, DSP plugin makes more sense for Foobar and a AU/VST plugin for Audirvana (or other plugin capable players). I plan to work on those, but do not have an ETA. With DSP, memory requirements can be addressed by choosing buffer size, but there is no free lunch. Longer will lead to better reconstruction accuracy) so you will still benifit with more RAM and faster processor.

 

 

 

 

[atxkyle]

+1 for the new 256 bit version. I’ve been transfixed by Coldplay’s Parachute’s this morning which sounds unequivocally the best it ever has on my system. The ultra-black background, the texture of the instruments, the euphony of the way certain chords ring… I agree with KennyB and AustinPop’s adjectives above. 

 

I also just moved from single sub to stereo subs setup this week (which also does very nice things to improve spatial cues for transparency, realism etc) so I confess I can’t 100% deconvolve the contribution of PGGB 256 vs the sub setup. But when comparing vs. the original 44.1 tracks, I think the delta is bigger than with previous PGGB versions. 

[Always.Learning]

I'd like to chime in on PGGB-256. Prior to PGGB-256 I had hundreds of albums that I had "blasted" (processed or remastered) at 64, 128, and 192 bits. With the advent of PGGB-256, I have re-blasted many of those albums at 256 and have also listened to many new albums blasted at 256. As part of the group that helped perform listening tests with the new software, I also experienced various technical advances during the process of refining PGGB-256. 

The jump in sonic quality from earlier versions of PGGB to the 256 versions is very real. Generally, what I hear is greater precision, truer timbre, and simply more lifelike reproduction. Transparency was already high with earlier versions. Comparing native files to the same files processed with 256, the leap in transparency is astonishing -- the kind of change that hits you in the face.

 

It is also worth pointing out that 256 is working magic on SACDs and DSD that has been ripped or downloaded. I always considered my Chord DAVE to be a PCM champion and so tended not to listen to much DSD. That has changed. Listening to SACD rips of Kind of Blue, Abraxas, and Ella and Louis has been one of the great surprises and pleasures of 256. 

 

For $1000, the PGGB license is gigantic bang for the buck. The license is very reasonably priced in light of the ability to improve virtually every digital source file, but there are two factors that I know have kept some people on the sidelines: 1) the cost of hardware needed to run PGGB; and 2) the time required to run the program. The good news is that these barriers to entry have become much easier to surmount with 256. You no longer need a server class computer to run PGGB. A wide variety of much less expensive consumer class machines will work. See remastero.com for more details on hardware requirements. Further, processing time is much, much faster now. You can easily process 10-15 albums in a single day -- way more than you'll be able to listen to in the same time frame. 

I have zero financial interest in PGGB -- I'm just thankful I have access to this amazing tool. 

 

[gtl]

Has the hardware requirements been lowered for MacOS with the latest PGGB 256? I would get a M1 Pro MacBook or a M2 Pro Macbook with 16gb of ram along with PGGB 256. Mostly listen to redbook or 24bit PCM with the occasional DSD64. Can the files be processed?

[Zaphod Beeblebrox]

5 hours ago, gtl said:

Has the hardware requirements been lowered for MacOS with the latest PGGB 256? I would get a M1 Pro MacBook or a M2 Pro Macbook with 16gb of ram along with PGGB 256. Mostly listen to redbook or 24bit PCM with the occasional DSD64. Can the files be processed?

While the requirements have dropped; I would recommend at least 32GB of RAM on Mac as Mac does not provide a user configurable way to increase virtual memory useful when the processing will not fit in available RAM). 

[austinpop]

16 hours ago, gtl said:

Has the hardware requirements been lowered for MacOS with the latest PGGB 256? I would get a M1 Pro MacBook or a M2 Pro Macbook with 16gb of ram along with PGGB 256. Mostly listen to redbook or 24bit PCM with the occasional DSD64. Can the files be processed?

 

I would also suggest that running PGGB on a laptop, even with adequate memory should only be considered for occasional use. When running PGGB on a bunch of albums, you will have sustained periods of high resource (CPU, memory, disk) utilization for hours, so a system with good cooling is essential. Laptops in general are designed for interactive use, not for sustained workloads, which can cause your fans to run loud, and heat to build up, possibly resulting in CPU throttling. I'm not saying every machine will do that, but just as a general guideline.

 

A desktop computer with a good CPU cooler, and a case with good airflow, is a much more sensible option.

[austinpop]

To give an indication of just how much faster PGGB-256 v5 is, compared to PGGB-AP v3, I went back and found some runs from v3, which I compared to my latest runs on v5. The speedup results are impressive! To summarize:

• On these 3 examples, v5 completed PGGB resampling 4.5x to 6.5x faster,
• While processing at a higher 256-bit precision compared to 192-bit in v3, for the PCM albums, and
• 256-bit precision compared to 128-bit in v3, for the DSD album. Why only 128-bit on v3? My machine had insufficient memory to run v3 at 192-bit precision for DSD inputs.
• I've yet to encounter a track that caused an out-of-memory error, or resulted in severe paging on v5 running PGGB at the full 256-bit precision on my 128GB RAM machine, even on my torture tracks that exceed 30 min duration in DSD or DXD resolution. On v3, such tracks could not be processed on my machine until I dropped down to 128- or even 64-bit precision, and even then they would cause severe paging in the system.

 

Timing Comparisons v3 vs v5

 

 

Native sample rate 24/96

Track duration range: 4-10 mins

 

                                    v3 @ p192   v5 @ p256    Speedup

Time to process album     11h, 47m     2h, 38m        4.5x

 

 

 

 

Native resolution: 16/44.1

Track length range:1-6 mins

 

                                    v3 @ p192   v5 @ p256    Speedup

Time to process disc 2       7h, 18m     1h, 22m        5.3x

 

 

 

 

Native resolution: DSD64

Track length (disc 1): 24 mins

 

                                    v3 @ p128   v5 @ p256    Speedup

Time to process Disc 1          15h, 47m          2h, 26m         6.5x

 

 

[austinpop]

Fixed the images in previous post.

[LowOrbit]

OK - so I got back from the US 6am Saturday, so other than dowloading the new version of PGGB, reading the updated documentation and trying out a couple of tracks I wasn't really in fit state to make an evaluation. (Though apparently I snored loudly on the couch for a good long while😁).

 

Since then ears recovered and what passes for normal brain function restored, I found time to run a few known tracks through the new PGGB on Sunday and definitely liked what I heard. Purchased new license pretty soon after that.

 

Jeez, this is so much faster, even with EQ (which was always one of the big time factors with earlier PGGB versions, and I can't live without some EQ for my Raal's). I am so pleased with this as it saves me spending a lot more cash on computing hardware.

 

Soundwise, yes, I can hear immediately that PGGB 256 is quite different to the previous AP versions. Leading notes in complex piano runs are much more clearly delineated, instrument separation is remarkable and musical flow is more compelling. Vocals are definitely clearer making some lyrics easier to discern but the depth , body and nuance to voices is one of the most compelling improvements.

 

This is an excellent upgrade and brings a fresh perspective I think on recordings I though I knew very well.

 

Thanks ZB and the testing team. 

 

 

 

[Zaphod Beeblebrox]

On 1/24/2023 at 12:10 AM, gtl said:

Has the hardware requirements been lowered for MacOS with the latest PGGB 256? I would get a M1 Pro MacBook or a M2 Pro Macbook with 16gb of ram along with PGGB 256. Mostly listen to redbook or 24bit PCM with the occasional DSD64. Can the files be processed?

I have some more information on the memory requirements. Compared to both the original PGGB and PGGB-AP, even at a precision of 256 bits, PGGB 256 is a lot more memory efficient. 

 

PGGB 256 uses adaptive algorithms that do not compromise on the quality of reconstruction to fit in available RAM (previously one could do this by setting taps). Currently the reconstruction quality at a given precision does not change, instead PGGB 256 adapts the processing pipeline to fit in memory and trades speed to achieve this (i.e., runs slower, to make sure the data being processed fits in memory).

 

What this means is one could do a lot more with 16GB RAM and PGGB 256 than previously possible. But there is still a limit to how much can be made it fit in RAM. At the minimum one needs enough RAM to hold the input data and upsampled data. So, this memory requirement depends on a few factors:

• Length of the track you are processing
• Input rate of the track (CD vs Hi-Res vs DSD etc.)
• Output rate (which depends on your DAC and settings, if you are upsampling to 705/768khz or 352.384kHz)
• Precision (64, 128 or 256 bit)

 

It is possible to estimate the memory requirements, so that is what I did, I simulated what is possible with 16GB of RAM (these are still estimates and should be considered approximate, it is best to try on a PC or laptop to confirm). I have also attached a pdf. Below is a summary of what to expect with 16GB.

 

Macs do not allow user configuration of swap files but typically allow swap file to grow to at least half of available RAM, so on a Mac, the maximum I will be comfortable with is a max processing memory of 24GB on a Mac with 16GB RAM. Below all the cells marked with orange imply you will hit a limit on a 16GB Mac.

 

• If you are upsampling to 8fS (353/384kHz), you should be fine with most tracks within 12minutes of length even at 256 bit precision.
• If you are upsampling to 16fS (705/768kHz), you should be fine with most tracks within 12minutes of length up to 128bit precision. 
• If you are upsampling to 16fS (705/768kHz), you should be fine with most tracks within 6minutes of length up to 256bit precision.

 

For Windows, with 128GB of VM allocated, up to 12minute track at 256 bit precision would not be an issue (it would page for 16fS upsampling and would be slow). Here too 32GB RAM will be good to have.

 

I also have a datapoint. Somone with the new Mac 16" M2 pro with 16GB RAM did this album at 256 bit precision to 16fS in 2 hours, 12 minutes. The same album took on a PC with 16 core Threadripper 1950x and 128gb ddr4 1 hour and 2 minutes. 

 

Compare memory 256.pdf

[austinpop]

1 hour ago, Zaphod Beeblebrox said:

I have some more information on the memory requirements. Compared to both the original PGGB and PGGB-AP, even at a precision of 256 bits, PGGB 256 is a lot more memory efficient. 

 

PGGB 256 uses adaptive algorithms that do not compromise on the quality of reconstruction to fit in available RAM (previously one could do this by setting taps). Currently the reconstruction quality at a given precision does not change, instead PGGB 256 adapts the processing pipeline to fit in memory and trades speed to achieve this (i.e., runs slower, to make sure the data being processed fits in memory).

 

What this means is one could do a lot more with 16GB RAM and PGGB 256 than previously possible. But there is still a limit to how much can be made it fit in RAM. At the minimum one needs enough RAM to hold the input data and upsampled data. So, this memory requirement depends on a few factors:

• Length of the track you are processing
• Input rate of the track (CD vs Hi-Res vs DSD etc.)
• Output rate (which depends on your DAC and settings, if you are upsampling to 705/768khz or 352.384kHz)
• Precision (64, 128 or 256 bit)

 

It is possible to estimate the memory requirements, so that is what I did, I simulated what is possible with 16GB of RAM (these are still estimates and should be considered approximate, it is best to try on a PC or laptop to confirm). I have also attached a pdf. Below is a summary of what to expect with 16GB.

 

Macs do not allow user configuration of swap files but typically allow swap file to grow to at least half of available RAM, so on a Mac, the maximum I will be comfortable with is a max processing memory of 24GB on a Mac with 16GB RAM. Below all the cells marked with orange imply you will hit a limit on a 16GB Mac.

 

• If you are upsampling to 8fS (353/384kHz), you should be fine with most tracks within 12minutes of length even at 256 bit precision.
• If you are upsampling to 16fS (705/768kHz), you should be fine with most tracks within 12minutes of length up to 128bit precision. 
• If you are upsampling to 16fS (705/768kHz), you should be fine with most tracks within 6minutes of length up to 256bit precision.

 

For Windows, with 128GB of VM allocated, up to 12minute track at 256 bit precision would not be an issue (it would page for 16fS upsampling and would be slow). Here too 32GB RAM will be good to have.

 

I also have a datapoint. Somone with the new Mac 16" M2 pro with 16GB RAM did this album at 256 bit precision to 16fS in 2 hours, 12 minutes. The same album took on a PC with 16 core Threadripper 1950x and 128gb ddr4 1 hour and 2 minutes. 

 

Compare memory 256.pdf 63.73 kB · 3 downloads

 

Just want to clarify, in case it wasn't clear, that all the numbers in the table are virtual memory. 

 

On WIndows, the available virtual memory is approximately (Physical RAM + paging file(s) size). So, even if you don't have the required physical RAM, your runs will not fail, if the total amount of virtual memory is sufficient. The only downside is that the bigger the difference between the memory required and the actual RAM, the more your system will be paging, i.e. writing memory pages to and from disk. This is why a fast SSD is crucial for your paging file.

[Zaphod Beeblebrox]

On 1/25/2023 at 10:16 AM, Zaphod Beeblebrox said:

I have some more information on the memory requirements. Compared to both the original PGGB and PGGB-AP, even at a precision of 256 bits, PGGB 256 is a lot more memory efficient. 

 

PGGB 256 uses adaptive algorithms that do not compromise on the quality of reconstruction to fit in available RAM (previously one could do this by setting taps). Currently the reconstruction quality at a given precision does not change, instead PGGB 256 adapts the processing pipeline to fit in memory and trades speed to achieve this (i.e., runs slower, to make sure the data being processed fits in memory).

 

What this means is one could do a lot more with 16GB RAM and PGGB 256 than previously possible. But there is still a limit to how much can be made it fit in RAM. At the minimum one needs enough RAM to hold the input data and upsampled data. So, this memory requirement depends on a few factors:

• Length of the track you are processing
• Input rate of the track (CD vs Hi-Res vs DSD etc.)
• Output rate (which depends on your DAC and settings, if you are upsampling to 705/768khz or 352.384kHz)
• Precision (64, 128 or 256 bit)

 

It is possible to estimate the memory requirements, so that is what I did, I simulated what is possible with 16GB of RAM (these are still estimates and should be considered approximate, it is best to try on a PC or laptop to confirm). I have also attached a pdf. Below is a summary of what to expect with 16GB.

 

Macs do not allow user configuration of swap files but typically allow swap file to grow to at least half of available RAM, so on a Mac, the maximum I will be comfortable with is a max processing memory of 24GB on a Mac with 16GB RAM. Below all the cells marked with orange imply you will hit a limit on a 16GB Mac.

 

• If you are upsampling to 8fS (353/384kHz), you should be fine with most tracks within 12minutes of length even at 256 bit precision.
• If you are upsampling to 16fS (705/768kHz), you should be fine with most tracks within 12minutes of length up to 128bit precision. 
• If you are upsampling to 16fS (705/768kHz), you should be fine with most tracks within 6minutes of length up to 256bit precision.

 

For Windows, with 128GB of VM allocated, up to 12minute track at 256 bit precision would not be an issue (it would page for 16fS upsampling and would be slow). Here too 32GB RAM will be good to have.

 

I also have a datapoint. Somone with the new Mac 16" M2 pro with 16GB RAM did this album at 256 bit precision to 16fS in 2 hours, 12 minutes. The same album took on a PC with 16 core Threadripper 1950x and 128gb ddr4 1 hour and 2 minutes. 

 

Compare memory 256.pdf 63.73 kB · 15 downloads

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.

 

 

 

Compare memory 256.pdf

[Zaphod Beeblebrox]

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

[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)?

[Zaphod Beeblebrox]

43 minutes ago, Atriya said:

 

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)?

Great question! I wish I had added that to my original post. The values I provided are for PCM rates 1fS, 2fS, 4fS, 8fS and also DSD 64 through DSD 1024 (or higher if any exists)!

 

While there is a slight uptick in memory requirement for increasing PCM rates, for DSD, the memory requirement does not change with increased rate. It depends only on the output rate you choose and track length.

 

In other words, a 10minute DSD 64 track would need the same amount of memory as DSD 256 as long as you are choosing the same output sample rate and also bit precision. But DSD 256 will take about 4x more time to process compared to a DSD 64 track of same length because there are simply 4x more samples to process.

[austinpop]

To reinforce ZB's sizing guide above, here is a data point in the form of a resource profile on my machine. Details of my machine:

• i7-10700 8-core CPU
• 128GB RAM
• 800GB paging file on C drive, resulting in
• 909GB total available VM, or virtual memory ("committed" value in Task Manager).

In the graph below, the Y-axis represents utilization of the paging disk or the C: drive in my case, and % of total available VM (virtual memory) for memory utilization. This is the memory and paging disk utilization profile, when running PGGB for:

• a DSD64 file
• 32m, 32s track duration
• 32/705.6 output
• 256-bit precision.

 

 

Interpretation

• My physical RAM of 128GB is 128*100/909 = ~14% of total available VM. Anytime VM utilization exceeds this threshold, it is possible for paging to occur
• You can see on the graph that once the VM consumption exceeded 14%, there were indeed bursts of disk activity, indicating the onset of paging
• Yet, in an overall sense, I would characterize the incidence of paging in this run to be light. That's because even if virtual memory is consumed due to allocation in the application, the memory actually has to be accessed to trigger paging. 

How does this relate to ZB's sizing table? His table indicates that a 128GB machine can handle tracks up to 48m in duration with minimal paging, and this is what I'm seeing on this resource profile for a 32 min track.

[Zaphod Beeblebrox]

3 hours 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 · 7 downloads

 

@austinpophad explained it in an earlier post, but I want to reiterate:

 

Track lengths reported in green (for Mac and Windows) assumes a total virtual memory of at least 1.5XRAM is available for allocation and those in pink (for Windows) assumes a total virtual memory of at least 2.5XRAM is available. Total Virtual memory = RAM + Swap file(s). The amount of virtual memory may be limited by other running processes including the OS.

 

On Mac, user has no control over how much and what rate swap files can grow, so a conservative estimate is about half of the total RAM. However, if there are other running processes, the amount of actual available virtual memory for PGGB will be much lower. Closing all apps and doing a restart of your Mac would give a good idea of how much RAM is left (I use iStat menu app in Mac). So the values reported for Mac can be a too optimistic if there are number of processes running. So, one needs to account for reduced RAM available when figuring out the longest track that can be processed.

 

On windows, it is possible to increase swap file size by changing virtual memory settings. This provides enough freedom for the reported maximum track lengths to be close to what is possible with available RAM.