remastero -> PGGB -> FAQ

How long does PGGB take to remaster a CD album?

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.

If using quad precision (Insane) expect the above timings to increase 1.5 folds and if using octuple precision expect it to increase 3 folds

It looks like PGGB can process really fast, can it do this on streamed music?

There is a real-time version available for Foobar2000 as a plugin. This version is limited to 64bit precision.

PGGB is available in a SDK form for OEM, for that exact purpose. SDKs are available for Windows, Mac and Arch Linux. The SDK is in the form of C++ header file and static libraries.

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 We 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 our tests indicate after just a few seconds of startup delay, gap-less playback is possible.

Are linear phase filters better for upsampling?

Upsampling requires a low pass filter ( to interpolate intermediate samples). The purpose of the filter is to provide good estimates of the intermediate samples so that the upsampled signal is smooth and as close to what the original music signal would have been.

There are several ways to implement the low pass filter and each method has its pros and cons. Linear phase filters maintain the phase relationship of the original signal and tend to preserve the timing of the original signal, resulting in improved imaging precision. Minimum phase filters when compared to linear-phase filters of the same length, have better frequency domain performance that results in better tonal accuracy and a denser presentation,

For the above reason, for short lengths, minimum phase have a significant advantage over linear phase filters. With longer filter lengths, the choice becomes more subjective and comes down to preference and synergy with the playback chain.

With, the ultra-long windowed Sinc based linear filters such as the one PGGB-AP uses, it is possible to get very close to the original, as if the music was recorded at a higher sample rate. As a result, the ultra-long filters pull ahead of other implementations in terms of realism and accuracy.

The ultra-long windowed Sinc based linear filters come with a significant cost in terms of latency and computational requirements, which make them hard to use for real-time playback. However, for offline upsampling and remastering, they are an excellent choice.

PGGB 256 use a proprietary method different from the above methods. PGGB 256 is non apodizing and it does not use windowed sinc functions, or long filters either. The best way to look at the current approach used by PGGB is that it considers the track as a whole. If no HF filters are enabled (which is the default for CD and 2fS rates), PGGB keeps all of the original samples intact, then creates intermediate samples all at once by time shifting all of the original samples. Our method approaches the theoretical limit of reconstruction accuracy possible for a track of given length and sample rate. This is more accurate than using pure Whittaker-Shannon coefficients with windowing. As the sample rate increases, and the track length increases, our method approaches the mathematical equivalence of using pure sinc based interpolation.

Why use noise shaping? Is it same as dither?

Both dither and noise shaping can be used to reduce the audible effects of quantization (i.e., digital noise). Quantization noise is introduced when the remastered track that resides in memory in 64-bit floating-point precision format, but needs to be output at 32-bit integer precision or lower. However they work in very different ways. Dither is the process of adding an intentional small random noise to randomize quantization noise. This serves to decorrelate the music signal and quantization error, resulting in a more natural sound. Dither does not reduce the quantization noise, it just helps to mask it.

Noise shaping does not simply mask the quantization noise, but it instead pushes the noise out of the audible range. Well implemented noise shapers can almost completely eliminate quantization noise from the audible range. This helps preserve and reproduce even the smallest of changes accurately, resulting in a clean and almost analog like quality. While noise shaping provides better results, unlike dithering, noise shaping can only be used if the output sample rate is 8fS (DXD) or higher.

PGGB uses specially designed higher order noise shapers that are optimized for output sample rates and bit depths and are designed to almost completely remove quantization noise from the audible range.

What is a 'HF Noise filter'?

HF noise filter refers to 'High frequency' noise filter. Most Hi-res recordings (4fS or higher) contain a significant amount of residual noise (beyond 30kHz) as a result of noise shapers used during analog to digital conversion process. There is no music information contained in this noise. So the HF noise can be safely removed, and has a positive effect on sound quality.

PGGB offer a choice of three HF noise filters. However the HF noise filters are not applied separately, instead they are integrated into the design of resampling process. Just like adding more elements to a camera lense can reduce transparency, using additional filters can reduce transparency. So PGGB uses a single optimized process that does both reconstruction and HF noise filtering for the most transparent sound.

Does PGGB 256 use Apodizing filters?

PGGB 256 does not use apodizing filters.

Apodization in Greek means cutting off the foot. It has different technical meanings depending on the application. In Signal processing, it just means using a windowing function to reduce ringing artifacts due to the abrupt truncation at the beginning and end of a sample window. In digital-audio, the term has been used and also misused. In digital-audio, more often than not 'apodizing' is used to mean it is a non-brick-wall filter which has reduced or no 'pre-ringing'. It is implemented as a slow-roll off filter.

Will my DAC benefit from PGGB? Does it need to be PCM DAC?

A DAC need not be pure PCM to take advantage of PGGB, Instead, the DAC would need to be able to accept higher rate PCM (preferably 16fS or more), which both R2R DACs such as Holo Spring May, Denafrips Terminator+ and delta-sigma DACs such as Chord DAVE and iFi DSD can do (this is not meant to be a complete list of DACs, just examples).

The idea here is to provide the DAC with a highest rate remastered version of the original music track that the DAC would accept (for example, this could be 705.6kHz or 1411.2kHz etc) and if these remastered track is as close to a true recording made at those rates, then the DAC will likely benefit from these remastered tracks as a bulk of the heavy lifting has already been done. If the DAC does not do any further processing (like R2R DAC in NOS mode) or if the DAC is able to take advantage of the higher rate PCM input (such some delta-sigma DACs that allow you to turn off oversampling filters) it is likely to benefit even further.

There are DACs that accept up to DXD rates and they may internally resample to much higher rates. These DACs would benefit only to the extent to which they can take advantage of DXD rates.

Please refer to 'Dacs and Players' section for more information.

Note: If it is possible to keep the processing on your DAC to minimum, it is better. Depending on your DAC, this may require your DAC to be in NOS mode. If that is not an option, turing off additional filtering. If you are forced to choose a filter, then choose a linear filter for best synergy with PGGB.

Does PGGB support DSD upsampling?

PGGB supports converting all DSD rates to PCM, but it does not currently support creating higher rate DSD.

The reason for not supporting DSD upsampling is that it is quite challenging to achieve the same signal-to-noise ratio and time domain accuracy of higher rate PCM using single bit DSD even at very high rates such as DSD512 or DSD1024. This requires designing high quality, stable higher order (perhaps seventh order or higher) modulators. Which is difficult, but perhaps not impossible to design.

We are currently researching this and we may implement it if there is a significant interest for DSD upsampling using PGGB. If you know of DAC(s) that can benefit more from DSD upsampling (compared to PCM upsampling), please drop us an email.

What is 1fS, 2fS, ..., 32fS etc?

One useful concept to learn is the terminology of FS. This refers to 'Fundamental Sample rate'. 1fS refers to 44.1 or 48 kHz. Thus:

How big are PGGB remastered tracks?

As a rule of thumb, every 11 minute 25 seconds of a stereo track at 16fS and 32 bits takes up about 4GB of space (which is the maximum size for 32 bit wav files). So, on an average typical CDs that are 40 - 45 minutes long will take about 16GB of space at 16fS 32 bits. At 8fS 32 bits that is 8GB and at 8fS 24 bits it will be 6GB.

Remastered tracks that are bigger than 4GB will be split, but the metadata is preserved and track numbering is changed so that they will play sequentially and in a gap-less fashion.

Does PGGB support lossless compression?

PGGB supports FLAC for bit depths less than or equal to 24 bits and sample rates less than 8fS.

PGGB also supports WavPack compression format for higher than 8fS rates or bit depth higher than 24 bits. WavPack compression is also lossless like FLAC.

PGGB will transfer all tags and artwork to both FLAC and WavPack output files.

What sort of PC will I need for running PGGB?

PGGB consumes s a memory-intensive application — for necessary reasons.
Recommended system specification:

• At least 4 cores, 8 cores preferred
• 16GB RAM if processing Cds with tracks less than 12 minutes. For more flexibility, at least 32 GB is recommended, and 64GB or 128GB will reward you even more if your library and DAC call for it. For detailed memory requirements, see here
• A fast NVMe SSD for input and output files, and paging file
• Recommend at least 100GB paging file (see guide for details)

• Custom Quiet PC
• Taiko Audio Extreme
• Quiet PC Serenity 8 Office (quietpc.com): Nanoxia Deep Silence 1 Anthracite Rev.B Ultimate Low Noise PC ATX Case. ASUS PRIME Z370-A II LGA1151 ATX Motherboard. Intel 9th Gen Core i7 9700K 3.6GHz 8C/8T 95W 12MB Coffee Lake Refresh CPU. Corsair DDR4 Vengeance LPX 64GB (4x16GB) Memory Kit. Scythe Ninja 5 Dual Fan High Performance Quiet CPU Cooler. Gelid GC-3 3.5g Extreme Performance Thermal Compound. Palit GeForce RTX 2070 8GB DUAL Turing Graphics Card. FSP Hyper M 700W Modular Quiet Power Supply. Quiet PC IEC C13 UK Mains Power Cord, 1.8m (Type G). 2 x Samsung 970 EVO 2TB Phoenix M.2 NVMe SSD (3500/2500)
• 2010 Mac Pro running Parallels: It was able to run PGGB with 6 cores and 32 GB of RAM but currently running 12 cores and 128 GB. Parallels was given at least 4 cores and at least 28 GB.
• Streacom FC10 Alpha fanless chassis, Asus Prime Z490-A mainboard, Intel i7-10700 LGA1200 2.9 GHz CPU, CORSAIR Vengeance 128GB (4 x 32GB) DDR4 SDRAM 2666, OPTANE H10 256GB SSD M.2 for Windows 10 Pro OS, SAMSUNG 970 EVO Plus SSD 2TB M.2 NVMe with V-NAND Technology, HDPLEX 400W HiFi DC-ATX power supply.
• iMac Pro (2017) — 3.2 GHz 8-Core, 32 GB, 1TB, Apple Bootcamp, Windows 10
• iMac, 48GB RAM, 3.3 GHz four core i5. Running Windows 10 Pro under Bootcamp with a shared drive set up

• The sample rate of the source track: The higher the rate, the more virtual memory is needed
• The length of the track: The longer the track, the more virtual memory is needed

Can you suggest a sample PC build for PGGB that is also quiet?

Sure we can:

• Be quiet! Pure Base 500, No PSU, ATX, White, Mid Tower Case . Caveat - It’s a nice quiet case, but nothing great to look at.
• Prime B460-Plus, Intel® B460 Chipset, LGA 1200, HDMI, ATX Motherboard
• Core™ i7-10700 8-Core 2.9 - 4.8GHz Turbo, LGA 1200, 65W TDP, Retail Processor
• 128GB Kit (4 x 32GB) HyperX FURY DDR4 2666MHz, CL16, Black, DIMM Memory. Caveat - can easily start with 64GB
• 750 GA, 80 PLUS Gold 750W, ECO Mode, Fully Modular, ATX Power Supply
• Be quiet! Dark Rock 4, 160mm Height, 200W TDP, Copper/Aluminum CPU Cooler
• 2TB 970 EVO Plus 2280, 3500 / 3300 MB/s, V-NAND 3-bit MLC, NVMe, M.2 SSD

Can I use the Taiko Audio Extreme to run PGGB application?

As extreme as the Taiko Extreme is, it is not quite extreme enough out of the box to run PGGB. The Extreme has a stripped down installation and memory configuration that is optimized for SQ during playback. PGGB consumes all available system resources (and then some). The good news is that you can install PGGB on the Taiko Extreme and run it when you are not listening to music and not impact SQ.

To get PGGB to run on the Extreme, you must configure a paging file when upsampling. By default, the Extreme has the paging file disabled to maximize sound quality. To run PGGB, you will be turning on a paging file, running PGGB, then disabling the paging file and rebooting, then listening to music on your Extreme as you normally do (for convenience, you can listen to music with the paging file on, but there may be some SQ impact).

To turn on the paging file on your Extreme, from the Start menu, follow the following path: Start -> Windows System -> Control Panel -> System -> Advanced System Settings -> Advanced -> Performance Settings -> Advanced -> Virtual Memory Change

Select the drive on which you want to put the paging file (C: drive usually), and select “custom size.” Set to 135000 for both min and max. Click OK and you’re paging file is ready to go. When you turn on or increase the size of the paging file, you do not need to reboot. If you shrink it or disable it, you will need to reboot for the change to take effect. Note that the default configuration of the Extreme has the paging file disabled, because it could impact SQ. For best sound quality, turn on your paging file, run PGGB, then turn it off and reboot before listening to music.

If you’re doing a lot of PGGB work, give a listen to playback with and without the paging file to decide if the inconvenience of rebooting your system prior to music playback is worthwhile for you. At 48GB, the Taiko Extreme is at the minimum amount of memory that you need to run PGGB. Typically it does OK, but upsampling DXD files or processing DSD files pushing the system to its limits. If you’re processing overnight, you won’t notice, but enjoy a cup a coffee if you’re sitting there waiting for these more intensive processing jobs to run.

If I had both PCM and DSD versions of an Album, which do I choose to remaster?

Regarding DSD… there are so many factors that come into play: original recording format, original editing and mixing format, your DAC, etc., etc. Ultimately, it all boils down to a couple of key considerations:

• Is the DSD album the best-sounding version in your library? If so, just upsample with PGGB - it will uplift SQ.
• If you also own PCM versions of the album, or are aware of other PCM versions, by all means explore upsampling your best-sounding PCM version with PGGB, and then choose the best-sounding upsampled versions.

Mahler 2nd, Gilbert Kaplan, Vienna Philharmonic, DG hybrid SACD. I don’t know the details of the recording, editing, and mastering format. Played natively to my DAVE in DSD+ mode, the DSD layer sounds best, with the CD layer played in PCM+ mode second best. I upsampled both versions to 32/705.6 with PGGB, played back natively on DAVE in PCM+ mode (of course), and found the following to hold:

a) the upsampled DSD version still sounds better than the upsample CD version
b) the gap between the 2 versions shrunk. In other words, PGGB did more good to the PCM version, but the improvement to the DSD version was still extraordinary.

Das Lied von der Erde, MTT, SF Symphony, recorded in DSD64, but unclear what format it was edited and mixed in. I suspect it was PCM, but not sure. I own 3 versions: DSD and CD from the hybrid SACD, and 24/96 hi-res version purchased from Qobuz. Played natively on my DAVE, I find the 24/96 (2fS) version to sound best, with the DSD version 2nd best. After upsampling with PGGB:

a) The upsampled 24/96 version reigns supreme.
b) The gap between the upsampled 24/96 and upsampled DSD is greater than the native gap. This again suggests PGGB’s ability to impart magic is most with PCM, but DSD is also uplifted.

Does PGGB support multi-channel music?

PGGB currently does not support multi-channel PCM or DSD, but it is relatively easy to extend it to support multi-channel. If there is modest demand for it, or a requirement for a commercial application,we are open to offering multi-channel support. Just drop us an email.

Why do you use Matlab? Isn’t it really slow?

The core of PGGB processing for 64 bit, 128 bit, and 256 bit is written fully in C/C++ and that is why there is already a real-time option that is free and is available as a Foobar2000 plugin that runs at 64bit precision and does not use Matlab runtime. The PGGB C++ core is cross platform compatible and works on Windows, Mac and Linux. We maintain a Matlab interface for PGGB because it is really useful for plotting the objective data and it is also very easy to add new experimental tools or options. The Matlab interface is just a shell and the actual processing is assembly level optimized C/C++, and uses openmp to make full use of multi-core architecture.

For those who wan't to avoid Matlab, and want a light weight implementation, there is PGGB-IT. PGGB-IT is an app for PGGB from Audiowise. Audiowise has licensed PGGB's optimized C/C++ libraries from remastero and created an application for windows. Since PGGB-IT uses the same libraries as PGGB, it provides the same sound quality. PGGB-IT has a smaller footprint, and easy to use. It has additional options such as multi-channel support and more file output options and also supports concurrent processing of multiple tracks. In terms of features, PGGB-IT currently does not support plotting of objective metrics but otherwise is feature complete. You can find more information here. PGGB-IT currently supports Windows only, we have future plans to add Mac and Linux support too.

We do not intentionally design software that will require a lot of resources (RAM and time), in fact performance optimization is one of our areas of research. The reason PGGB takes so much resources is because 256bit computations of this nature take a lot of time. We are confident in saying that we have the fastest and most memory efficient implementation on the planet (if one considers the equivalence of using a filter that is about the same length as the number of samples in the track, computed at the output rate, with 256 bit precision). There is no free lunch, if one wants the ultimate quality in reconstruction, there are no shortcuts. We can of course design shorter filters that are faster and need less memory, but then it will not be PGGB any more, there are alternate options that do that.

It is very easy to compare speeds by setting 64bit, 128bit and 256bit precision in PGGB and see the difference in speed. Please be warned, if you are running a trial version processing will stop after 5 tracks at 64bits and at 3 tracks at 256 bit precision. So if you run PGGB in trial mode overnight, do not be surprised if you only see 3 processed tracks in 7 hours! It did not take 7 hours to process, it just stops after three tracks. For example, on a Windows PC with a 8-core, 3.6GHz i9 CPU and 64GB RAM, an average CD (44.1kHz) track converted to 16fS rate will be processed at about 1x - 0.8x speed at 256bit precision. There are both text and csv logs in the output folder that show the actual time taken.