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

23 minutes ago, happybob said:

thinking I may just buy a separate PC (have a need for that anyway) 

This was my situation (had a need anyway) and so I bought a new desktop with enough capacity. My config is listed on ZB's website here: https://www.remastero.com/faq.html#Sample

30 minutes ago, happybob said:

And related, how long does a given 44K track take to convert on a very high performance machine (like a Taiko Extreme)?

Ironically, while the Extreme is a music server par excellence, it isn't exactly the ideal machine to run PGGB — mainly due to its memory capacity of 48GB. Most Extreme owners I know have chosen to do their PGGB processing offline on more suitable hardware.

9 minutes ago, Zaphod Beeblebrox said:

It depends on the length of the track on CDs but, if you have at least 32GB of RAM and a fast drive for virtual memory, you can expect 3x or higher rate. So a typical CD album may take  15 - 20 minutes to process.

Exactly. We find a good metric to track processing speed is to use the ratio of track time/processing time. On my machine (above), I easily get 3.2-3.8x for Redbook tracks. Even "heavy" loads like long DXD tracks come in at over 2x.

38 minutes ago, ted_b said:

Does PGGB work on multichannel PCM as well?

It currently does not, but it is relatively easy to extend it to support multi-channel. I have several multi channel DSDs and a few multi channel Audio DVDs myself, and I have not got around to making the change. If there is modest demand for it, or a requirement for a commercial application, I am open to offering multi-channel support.

@ray-dude, @romaz and @austinpop here I thought you guys were just kicking back and enjoying your Extremes.  Great to hear you're continuing to explore new improvements.  Thanks for all your efforts, and of course thanks to Zaphod.  I'm looking forward to hearing how this impacts the music.  I'll be checking this out with the Hugo TT2 and Omegas as well as with the new Holo May in my main listening environment.  I know you guys are huge DAVE fans, but if you ever get the chance to listen to the May, I'd love to know what you think.  I'm very impressed so far and it's just breaking in.

I now have the PGGP trial and have made a bunch of files for comparison of your different "preferences".  I had been enjoying real time upsampling with HQP's sinc-L filter and LNS15 shaper.

13 minutes ago, Johnseye said:

@ray-dude, @romaz and @austinpop here I thought you guys were just kicking back and enjoying your Extremes.  Great to hear you're continuing to explore new improvements.  Thanks for all your efforts, and of course thanks to Zaphod.  I'm looking forward to hearing how this impacts the music.  I'll be checking this out with the Hugo TT2 and Omegas as well as with the new Holo May in my main listening environment.  I know you guys are huge DAVE fans, but if you ever get the chance to listen to the May, I'd love to know what you think.  I'm very impressed so far and it's just breaking in.

 

I now have the PGGP trial and have made a bunch of files for comparison of your different "preferences".  I had been enjoying real time upsampling with HQP's sinc-L filter and LNS15 shaper.

 

Between TT2+ Omegas at 16fs/32bit and the May at 32fs, that will be quite the shoot out!  Can't wait to hear what you hear!

23 minutes ago, Johnseye said:

.  I'll be checking this out with the Hugo TT2 and Omegas as well as with the new Holo May in my main listening environment. 

Looking forward to your impressions. My main rig is Chord DAVE directly driving Omega CAMs

I’m using a 2010 Mac Pro as my PGGB processing machine with Windows 10 running in Parallels.  It cost me like $350 a few years ago.  I initially spent $200 to max out RAM to 48 GB.  For Mac users who aren’t interested in buying a PC, this is a good inexpensive option.  
 

What’s cool about the 2010/2012 Mac Pros is that the CPU is easily upgradable by swapping in a new CPU tray.  I swapped out the single core tray for one containing two six core processors.  It processes PGGB without breaking a sweat.  

1 hour ago, Johnseye said:

@ray-dude, @romaz and @austinpop here I thought you guys were just kicking back and enjoying your Extremes.  Great to hear you're continuing to explore new improvements.  Thanks for all your efforts, and of course thanks to Zaphod.  I'm looking forward to hearing how this impacts the music.  I'll be checking this out with the Hugo TT2 and Omegas as well as with the new Holo May in my main listening environment.  I know you guys are huge DAVE fans, but if you ever get the chance to listen to the May, I'd love to know what you think.  I'm very impressed so far and it's just breaking in.

Hi John,

Long time no see. Hopefully we'll get to meet in person at AXPONA some year.

Yes indeed, I am indeed content to be off the hardware hamster wheel, but my ownership of the Extreme has just underscored the importance of software. PGGB has been a major exploration, but equally important has been the collaboration with Emile and the Taiko team on their TAS player, and other software tweaks.

You're teeing up an exciting comparison for sure! Are you able to run the May at 32FS? I've been tracking the discussion on the thread, and getting the thing to operate at 20/32FS seems to be difficult. Hopefully you'll at least get it to work at 16/32FS and at 20/16FS. And as Ray already mentioned, be sure to process content for the TT2 at 32/16FS.

I will be curious to know for each DAC, the SQ difference before and after PGGB. Additionally, how they both compare to each other with the best configuration of PGGB.

1 hour ago, Johnseye said:

I had been enjoying real time upsampling with HQP's sinc-L filter and LNS15 shaper.

 

This is still my configuration for listening to streaming music through Qobuz.

5 hours ago, austinpop said:

Exactly. We find a good metric to track processing speed is to use the ratio of track time/processing time. On my machine (above), I easily get 3.2-3.8x for Redbook tracks. Even "heavy" loads like long DXD tracks come in at over 2x.

Wow, this is faster than I thought for the conversion! It makes me wonder given that the SW can convert this fast, then perhaps some ability to playback streaming music might be in the cards too at some point soon? There's no playback capability of the PGGB SW (yet, perhaps never, but maybe somehow licensed to Roon, Taiko, or others) and the first track of an entire album would take a while to convert/buffer, the follow-on tracks could be converted by the time you got to them listening-wise. Now a separate issue of course is the noise in the machine doing the conversion, but still the ability to listen to Qobuz with this sort of upsampling would be really amazing!

8 hours ago, happybob said:

Wow, this is faster than I thought for the conversion! It makes me wonder given that the SW can convert this fast, then perhaps some ability to playback streaming music might be in the cards too at some point soon? There's no playback capability of the PGGB SW (yet, perhaps never, but maybe somehow licensed to Roon, Taiko, or others) and the first track of an entire album would take a while to convert/buffer, the follow-on tracks could be converted by the time you got to them listening-wise. Now a separate issue of course is the noise in the machine doing the conversion, but still the ability to listen to Qobuz with this sort of upsampling would be really amazing!

Yes, it looks like you read my mind :) PGGB is available in a SDK form for OEM, for that exact purpose.  

Developing a player from scratch that will both play local files and streaming audio is a huge undertaking, and also doing it the right way (managing buffers, load balancing and keeping any processing noise to an absolute minimum etc.) is even harder.

One option I had considered is for PGGB to sit in between an existing player and an endpoint or like a plugin. The problem with this approach is the latency will be unacceptable as PGGB in the middle will only have access to the stream at the rate at which the host application sends the data. For this reason, the only way I would implement PGGB in real time is if I had direct access to the full track or multiple tracks (this is possible even for streamed data as most players will cache the tracks in advance). 

The PGGB in SDK form uses a different framework for performance and is light weight and my tests indicate after  just a few seconds of startup delay, gapless playback is possible.

I’ve been able to trial a few PGGB converted files through a Hugo TT-2 and can confirm the increased realistic body of voices, instruments and ambient noted by previous posters. One step closer to having the live performance in my living room. Great stuff!

I mostly stream vs. purchase music, so am very interested in how the streaming PGGB options evolve. Would be very interesting to compare a PGGB streaming option vs. adding an M Scaler  vs. HQP upsampling. 

On 4/18/2021 at 2:49 AM, romaz said:

With real-time upsampling, because of the limitations of hardware, we could only get to 32 million taps initially and with massive time delays (>1 minute).  With offline upsampling, gone are the restraints of hardware and depending on the file and the length of the track, PGGB has provided me new masters with up to 4 billion taps.

Delay is unavoidable by-product of using long filters. If you process single file with 1M tap filter, by definition it needs to become 500k samples longer at both ends. 4 billion tap filter means it needs to become 2 billion samples longer at both ends...

There is no hardware limitation of doing more than 32 million taps in real-time either...

This is indeed an interesting new avenue for digital audio. Hats off to the developer @Zaphod Beeblebrox and all those who are involved in this project in various forms.

It looks like for Chord DACs its a no brainer. It would be worth a try for a Lampizator but I don't have the right resources, especially 64Gb RAM and 2tb NVMe drive. Before I invest into the h/w just to try it out, is there any sample available (both native and remastered) so that I can quickly see if it benefits my setup ?

If I understand, PGGB remastered track sounds better than HQP upsample. Is this true for all the DACs that has been tried so far or is it specific to Chord DACs ? Also, I dare to ask - has anybody compared HQP Pro offline processed files to PGGB ? I know there is a huge price difference but thought it might be an interesting question.

17 minutes ago, Dev said:

It would be worth a try for a Lampizator but I don't have the right resources, especially 64Gb RAM and 2tb NVMe drive. Before I invest into the h/w just to try it out

If you plan to do CDs for testing, 16GB  or 32GB May be ok, if you want to give it a try. I assume your DAC supports PCM up to 768khz 32 bits

15 hours ago, austinpop said:

You're teeing up an exciting comparison for sure! Are you able to run the May at 32FS? I've been tracking the discussion on the thread, and getting the thing to operate at 20/32FS seems to be difficult. Hopefully you'll at least get it to work at 16/32FS and at 20/16FS. And as Ray already mentioned, be sure to process content for the TT2 at 32/16FS.

I run the May without issue at 32/32FS but have set HPQe to 20/32FS as recommended. The only challenge is using an Intel based USB port and the firmware of the May must be 30.12 and not 30.14 to enable 32FS.

Regarding PGGB, I look forward to a streaming option to compare to HQPe/NAA. I really don't listen to enough local content to warrant the trouble but will likely trial it just to compare with HQPe.

1 hour ago, Dev said:

Also, I dare to ask - has anybody compared HQP Pro offline processed files to PGGB ?

Pro has the same algorithms as Desktop and Embedded, so if you process to just PCM, it won't sound any different than processing in realtime, and processing to PCM in realtime is not an issue to any extent. Where it becomes advantage is if you want to run EC modulators to DSD512 or higher.

If you want gapless, you need to process entire album at once, because naturally individual tracks processed alone will become longer depending your choice of filter. Most notable with longer filters like sinc-M or sinc-L. With entire album, only first and last track become longer.

16 hours ago, austinpop said:

 

Hi John,

 

Long time no see. Hopefully we'll get to meet in person at AXPONA some year.

I think we both still have our comp tickets waiting in the wings.  Looking forward to it as well as the CSO when we can start seeing the orchestra again.

16 hours ago, austinpop said:

 

 

You're teeing up an exciting comparison for sure! Are you able to run the May at 32FS? I've been tracking the discussion on the thread, and getting the thing to operate at 20/32FS seems to be difficult. Hopefully you'll at least get it to work at 16/32FS and at 20/16FS. And as Ray already mentioned, be sure to process content for the TT2 at 32/16FS.

 

I will be curious to know for each DAC, the SQ difference before and after PGGB. Additionally, how they both compare to each other with the best configuration of PGGB.

With a firmware "downgrade" I'm able to listen at 32FS.  The May shipped with a firmware version that made it more compatible with a wider variety of usb devices, but by doing so they limited that version to 16FS.  Mine now works perfectly at 32FS and will be upsampling some tracks with PGGB to listen this evening.  I expect to further be astounded and will share my experiences.

I do have an open question however as the May is a 32 bit dac.  Jussi has recommended output at 20 bit for the Holo Spring.  I'm curious as to why we wouldn't be creating 32 bit upsampled files, as you mention 20/32FS.  Was that based on feedback in the thread alone?

1 minute ago, Zaphod Beeblebrox said:

If you plan to do CDs for testing, 16GB  or 32GB May be ok, if you want to give it a try. I assume your DAC supports PCM up to 768khz 32 bits

Unfortunately, I run only 8Gb for sound quality reasons. Yes, the DAC supports 768khz 32 bits

41 minutes ago, Dev said:

 

Unfortunately, I run only 8Gb for sound quality reasons. Yes, the DAC supports 768khz 32 bits

We're still establishing which DACs will benefit from PGGB. 16FS (768) is a good sign. A NOS mode is another. A practical way to tell if it's worth trying PGGB is to first see if real-time HQP PCM upsampling using sinc-L/LNS15 produces an SQ uplift. If it does, then by all means try PGGB and see what you think.

1 hour ago, Johnseye said:

I expect to further be astounded and will share my experiences.

Looking forward to it.

Quote

I do have an open question however as the May is a 32 bit dac.  Jussi has recommended output at 20 bit for the Holo Spring.  I'm curious as to why we wouldn't be creating 32 bit upsampled files, as you mention 20/32FS.  Was that based on feedback in the thread alone?

I'll let the DSP experts talk to this, but my understanding is that R2R DACs have a region of linearity up to a certain level of precision, and this can be determined by looking at the published noise plots. I believe Jussi established that for the May, 20 bits was optimum — at least that's my recollection. If it's a different number like 22, please use that instead.

By setting Output Bit Depth in PGGB (or DAC Bits in HQP), you allow its noise shaper to set the output precision to be optimum for the DAC. When you select 20 bit output depth, PGGB will generate 20-bit samples, although they will be written out as 24-bit numbers in the WAV container (file). Then, when your music player sends these samples to the DAC, it may further pad these 24-bit samples to 32-bit, but this varies by DAC, and its USB controller (XMOS, Amanero, etc). So things can get complicated, but the ultimate idea of the output bit depth is that after the data has been transported and received at the DAC, the data is at exactly the right precision to match the linear range of the DAC.

@Zaphod Beeblebrox please correct any errors in my description!

EDIT: In contrast, the DAVE and other Chord DACs have been found to sound best with Output Bit Depth set to 32. We suspect this is related to the Amanero controller used in these DACs, which is why DAVE users are advised to generate 32/16FS files with PGGB. 

16 minutes ago, austinpop said:

EDIT: In contrast, the DAVE and other Chord DACs have been found to sound best with Output Bit Depth set to 32. We suspect this is related to the Amanero controller used in these DACs, which is why DAVE users are advised to generate 32/16FS files with PGGB. 

With DAVE when you input PCM you always have the remaining digital filters and delta-sigma modulator on the way before D/A conversion section. So you have bunch of DSP ongoing there. If you use USB input, you can provide that DSP 32-bit material to give as high as possible precision for further processing. If you use S/PDIF (coax or optical), or AES/EBU inputs, you are limited to 24-bit due to limitations of the connection method.

This is the same for any delta-sigma DAC with PCM inputs.

If you have R2R ladder in NOS mode, it is totally different, since the samples can actually reach the conversion stage.

1 hour ago, Johnseye said:

I do have an open question however as the May is a 32 bit dac.  Jussi has recommended output at 20 bit for the Holo Spring.  I'm curious as to why we wouldn't be creating 32 bit upsampled files, as you mention 20/32FS.  Was that based on feedback in the thread alone?

May DAC specs indicate 32bit, but it is a 24 bit R2R DAC and I wont be surprised if the last 8bits are just ignore/dropped (in NOS mode).

One of the biggest challenges designing R2R DACs is to ensure precision of the resisters they use and this can make or break the DAC. MAY DAC has one of the best  (if not the best) measured performance for R2R DACs and part of it is likely because of the 0.00005% resistor tolerance they report. In theory, for a R2R DAC to be perfect 'linearity', the required tolerance of the resistors will be about 100/2^24  approximately 0.000006%.  Linearity simply implies that as the digital input varies from 0 to maximum, the DAC's output also moves linearly. If the resistors do not have the required tolerance, the output will not be linear, especially for the last few significant bits. As a result the last few bits do more harm than good (which can be alleviated by noise shaping). 

In the case of May DAC, the published 0.00005% tolerance will be approximately equal to 21bits of precision (which is quite impressive), however measurements of linearity published by both Stereophile and ASR seem to indicate 20bits

55 minutes ago, austinpop said:

 

We're still establishing which DACs will benefit from PGGB. 16FS (768) is a good sign. A NOS mode is another.

 

I am not sure if Lampi operates in a NOS mode or if there is an SRC inside. There isn't enough information on this, I think. I will write to Lampi and see if they can provide any info on this.

1 hour ago, austinpop said:

A practical way to tell if it's worth trying PGGB is to first see if real-time HQP PCM upsampling using sinc-L/LNS15 produces an SQ uplift. If it does, then by all means try PGGB and see what you think.

Thanks for the pointer. I have never tried upsampling with the Lampi before but the Denafrips Terminator, which I no longer own, did benefit slightly. I will run some tests tonight (and in couple of days) to see if HQP sinc-L/LNS15 does anything better.

8 hours ago, Zaphod Beeblebrox said:

Yes, it looks like you read my mind :) PGGB is available in a SDK form for OEM, for that exact purpose.  

Developing a player from scratch that will both play local files and streaming audio is a huge undertaking, and also doing it the right way (managing buffers, load balancing and keeping any processing noise to an absolute minimum etc.) is even harder.

 

One option I had considered is for PGGB to sit in between an existing player and an endpoint or like a plugin. The problem with this approach is the latency will be unacceptable as PGGB in the middle will only have access to the stream at the rate at which the host application sends the data. For this reason, the only way I would implement PGGB in real time is if I had direct access to the full track or multiple tracks (this is possible even for streamed data as most players will cache the tracks in advance). 

 

The PGGB in SDK form uses a different framework for performance and is light weight and my tests indicate after  just a few seconds of startup delay, gapless playback is possible.

This would be truly awesome if someone grabs the PGGB tech and runs with it for a player. Personally, I'd love to see Roon do this and I imagine it's fully possible, but perhaps the biggest challenge might be convincing them that their upsampling tech is not as good as the PGGB tech or that the difference (even once they're convinced) isn't worth the effort. Still though they are smart folk and maybe could even license your tech somehow and fold it into Roon as some "superenhanced upsampling" option right in the UI! And if not them, maybe someone else hopefully!

As far as I'm aware a software audio player already exists in the form of Xxhighend which has been upsampling for over 10 years to 32/768 and playing back on the fly, all in Ram. I do see this new PGGB upsamples to a higher state than Xxhighend does currently.

In order to get the best from playing back in this state has always involved high powered PC's. For Xxhighend, Xeon processors with multiple cores, linear power supplies and high Ram capacity. 

Sound wise Xxhighend in my view has always been the best to date, albeit tricky to master, for sound for PCM audio file reproduction.

Good to see anyone push the barrier though.

Robert