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

[Zaphod Beeblebrox]

29 minutes ago, Markus8 said:

Isn’t HQPlayer capable of doing that too?

Your question is missing some context. The original question was if there was a downside to oversample using two different approaches, the first being done by PGGB to 16fS rates and then further use the up sampling and DSD modulation using the other software. 

[mpaulson540]

I have been having good results experimenting with PGGB (trial version) @ 128 upsampling files to 16fs/32bit PCM and then playback through Roon/HQPlayer ASDM7EC-Light poly-sinc-gauss-hires-lp 256DSD to a Denafrips Ares II. This seems to hit a sweet spot with processing requirements and since I already own HQPlayer, makes considering PGGB at 128 a little easier to swallow. 16fs PCM is also recognized by Roon as opposed to 32fs. I am only a week into the trial so still learning but pleased at the results with the combo so far. 

[mpaulson540]

3 hours ago, mpaulson540 said:

I have been having good results experimenting with PGGB (trial version) @ 128 upsampling files to 16fs/32bit PCM and then playback through Roon/HQPlayer ASDM7EC-Light poly-sinc-gauss-hires-lp 256DSD to a Denafrips Ares II. This seems to hit a sweet spot with processing requirements and since I already own HQPlayer, makes considering PGGB at 128 a little easier to swallow. 16fs PCM is also recognized by Roon as opposed to 32fs. I am only a week into the trial so still learning but pleased at the results with the combo so far. 

 

Just a quick follow-up to my previous post - as recommended by Zaphod in a previous post about creating 16 fs and 64 bit output files when using PGGB and HQPlayer together, I am also using Roon for HQP/Qobuz and find that Roon does not recognize the 64 bit output file created by PGGB. Consequently, I have been creating 16fs/32bit output files.   

[Zaphod Beeblebrox]

19 hours ago, mpaulson540 said:

 

Just a quick follow-up to my previous post - as recommended by Zaphod in a previous post about creating 16 fs and 64 bit output files when using PGGB and HQPlayer together, I am also using Roon for HQP/Qobuz and find that Roon does not recognize the 64 bit output file created by PGGB. Consequently, I have been creating 16fs/32bit output files.   

 

That is interesting, Roon will use 64bit wav files for convolution EQ! I am assuming you are using  .wav files from PGGB?

[mpaulson540]

1 hour ago, Zaphod Beeblebrox said:

 

That is interesting, Roon will use 64bit wav files for convolution EQ! I am assuming you are using  .wav files from PGGB?

Yes, apparently Roon only supports wav files up to 32 bit 768 khz. A Roon user provided this link to me today.

 

https://help.roonlabs.com/portal/en/kb/articles/faq-what-audio-file-formats-does-roon-support

[taipan254]

1 hour ago, mpaulson540 said:

Yes, apparently Roon only supports wav files up to 32 bit 768 khz. A Roon user provided this link to me today.

 

https://help.roonlabs.com/portal/en/kb/articles/faq-what-audio-file-formats-does-roon-support

 

So weird. 

 

FWIW - I avoid Roon altogether (though I own a lifetime license). For files I have gargle-blasted, I use HQP and HQP Client (that is, I set up a server using HQPlayer only). For streaming, I use HQPlayer + Qobuz again through HQP only (no Roon). 

 

I typically browse albums on the Qobuz app on my phone, favorite them when I want to listen to them, and if I like what I listen to I purchase the album and gargle blast it. 

 

The last time I checked, Roon sounded worse than going from HQP direct. I liked Squeezelite a lot, but could never get it to work with gargle blasted files, sadly.

[LowOrbit]

1 hour ago, taipan254 said:

 

So weird. 

 

FWIW - I avoid Roon altogether (though I own a lifetime license). For files I have gargle-blasted, I use HQP and HQP Client (that is, I set up a server using HQPlayer only). For streaming, I use HQPlayer + Qobuz again through HQP only (no Roon). 

 

I typically browse albums on the Qobuz app on my phone, favorite them when I want to listen to them, and if I like what I listen to I purchase the album and gargle blast it. 

 

 

Pretty much my current methodology (except I declined to follow up a Roon trial with hard cash). 64bit doubles, mostly at 16fs, but some acoustic recordings "seem" to become a little more vivid if I go to 32 or 64fs, but even my 30+tb of storage isn't adequate to house too much of that sort of nonsense 😁.

 

All files converted to DSD512 or 1024 in HQP at replay time.

 

I am quite impressed with the quality of unconverted streaming from Qobuz.

[mpaulson540]

10 hours ago, taipan254 said:

 

So weird. 

 

FWIW - I avoid Roon altogether (though I own a lifetime license). For files I have gargle-blasted, I use HQP and HQP Client (that is, I set up a server using HQPlayer only). For streaming, I use HQPlayer + Qobuz again through HQP only (no Roon). 

 

I typically browse albums on the Qobuz app on my phone, favorite them when I want to listen to them, and if I like what I listen to I purchase the album and gargle blast it. 

 

The last time I checked, Roon sounded worse than going from HQP direct. I liked Squeezelite a lot, but could never get it to work with gargle blasted files, sadly.

Yes, I agree, it does sound better going directly from HQPlayer or HQPlayer Client than using Roon. For local files and HQPlayer, it would be nice if Roon could simply drop the file into HQPlayer rather than streaming. I know many people have strong feelings about Roon here at AS but I really do like the interface/file organization/music suggestions/zones. I also like the interface with Qobuz and don't detect any difference in sound quality using Roon versus HQPlayer client streaming from Qobuz. Maybe just use Roon for organizing and finding?

 

Speaking about strong feelings: I want to believe that using a PGGB "pre-processed" file can't be better than using HQP alone. I certainly do not have the most high resolution system; Ares II -> Singxer SA-1 -> Hifiman Sundara headphones. Starting week two of my PGGB trial, trying to give myself time to compare a variety of music and let my ears settle since it is a pretty big investment in both time and money. Right now, the PGGB 16fs/32 bit files at 128 precision seem to sound better - more relaxed, more space, better timbre. They also seem to sound better to me through HQPlayer to DSD 256 rather than PCM with no HQP filters. Just wish there were a junior PGGB 128 16fs/32 clean version (just basic defaults with no eq/bells and or whistles) at a reduced cost.  

[mpaulson540]

9 hours ago, LowOrbit said:

Pretty much my current methodology (except I declined to follow up a Roon trial with hard cash). 64bit doubles, mostly at 16fs, but some acoustic recordings "seem" to become a little more vivid if I go to 32 or 64fs, but even my 30+tb of storage isn't adequate to house too much of that sort of nonsense 😁.

 

All files converted to DSD512 or 1024 in HQP at replay time.

 

I am quite impressed with the quality of unconverted streaming from Qobuz.

The 64 bit file produced is ginormous. I just have to wonder how much "air" it contains.

I will try Qobuz direct.  

[LowOrbit]

I use 64bit because I am running the file through HQPlayer and the modulator does the final noise shaping - better than having the process completed to 32 bits in PGGB then reshaped again to get the 1 bit stream for the dac. Be sure to disable sw volume control also - not good.

 

My feeling is this approach brings a little more micro dynamics and harmonic complexity out but we all hear things our own way and Miska and Zapped have given us many options from which to pick our particular poison.

[taipan254]

1 hour ago, mpaulson540 said:

Yes, I agree, it does sound better going directly from HQPlayer or HQPlayer Client than using Roon. For local files and HQPlayer, it would be nice if Roon could simply drop the file into HQPlayer rather than streaming. I know many people have strong feelings about Roon here at AS but I really do like the interface/file organization/music suggestions/zones. I also like the interface with Qobuz and don't detect any difference in sound quality using Roon versus HQPlayer client streaming from Qobuz. Maybe just use Roon for organizing and finding?

 

Speaking about strong feelings: I want to believe that using a PGGB "pre-processed" file can't be better than using HQP alone. I certainly do not have the most high resolution system; Ares II -> Singxer SA-1 -> Hifiman Sundara headphones. Starting week two of my PGGB trial, trying to give myself time to compare a variety of music and let my ears settle since it is a pretty big investment in both time and money. Right now, the PGGB 16fs/32 bit files at 128 precision seem to sound better - more relaxed, more space, better timbre. They also seem to sound better to me through HQPlayer to DSD 256 rather than PCM with no HQP filters. Just wish there were a junior PGGB 128 16fs/32 clean version (just basic defaults with no eq/bells and or whistles) at a reduced cost.  

I use PGGB-IT! 64. cheapest way to gargle blast to your heart’s content. 
 

https://audiowise-canada.myshopify.com/collections/pggb

 

[mpaulson540]

Can I verify that PGGB-256 (Version 5.3.46) creates 64bit output files that automatically have dither and noise shaping off?

This was discussed in prior messages but does not appear to be documented clearly in the User Guide (that I can find).

Since there appears to be a fair number of users using PGGB for pre-processing with HQP, maybe a section in the manual with recommendations would be helpful. I'm trying to cobble together a strategy using bits of messages which has bee a little tedious.  

 

For my ears and trying to keep storage requirements sane, 8fs at 64bit output mat be a better choice for HQPlayer DSD upsampling than 16fs at 32bit output as files sizes are identical. Using 128bit precision, I'm not sure I can hear a significant audible difference between the two versions with DSD256 upsampling in HQPlayer. Even with my limited system/ears, I can easily hear a difference between the raw 44.1 Aiff file versus PGGB 128-384-64 in HQP. Just need to live with it for a while. 

 

I am building a sample library with PGGB trial version to see if I will be happy just using HQPlayer/Client instead of Roon for local files.  I just need to be a little more organized.  For the time being I will continue to use Roon for streaming Qobuz only as I sort this out. Thanks in advance for your help. 

 

[mpaulson540]

Regarding the PGGB 64 bit output file using noise shaping/dither, I did look in the log file and found the following:

 

[24-01-13 07:54:04] Start NS [1]
[24-01-13 07:54:04] Switching to dither only [1]
[24-01-13 07:54:04] NS threads used: 8  for length 866 seconds each [1]
[24-01-13 07:54:08] Completed upsampling and NS [1]
[24-01-13 07:54:23] Total time for block: 330.0597 Seconds
[24-01-13 07:54:23] End upsampling block
[24-01-13 07:54:23]  writing upsampled blocks
[24-01-13 07:54:23] Processing upsampled block 1 of 1
[24-01-13 07:54:24] Bit depth: 64 Word length: 64
[24-01-13 07:54:33] Writing block 100 % done
 

Do I need to be at a hight sample rate than 8fs in order to avoid NS/Dither?

Just trying to keep the input file as clean as possible for HQP.

Advice?

 

[Zaphod Beeblebrox]

1 hour ago, mpaulson540 said:

Can I verify that PGGB-256 (Version 5.3.46) creates 64bit output files that automatically have dither and noise shaping off?

This was discussed in prior messages but does not appear to be documented clearly in the User Guide (that I can find).

Since there appears to be a fair number of users using PGGB for pre-processing with HQP, maybe a section in the manual with recommendations would be helpful. I'm trying to cobble together a strategy using bits of messages which has bee a little tedious.  

 

For my ears and trying to keep storage requirements sane, 8fs at 64bit output mat be a better choice for HQPlayer DSD upsampling than 16fs at 32bit output as files sizes are identical. Using 128bit precision, I'm not sure I can hear a significant audible difference between the two versions with DSD256 upsampling in HQPlayer. Even with my limited system/ears, I can easily hear a difference between the raw 44.1 Aiff file versus PGGB 128-384-64 in HQP. Just need to live with it for a while. 

 

I am building a sample library with PGGB trial version to see if I will be happy just using HQPlayer/Client instead of Roon for local files.  I just need to be a little more organized.  For the time being I will continue to use Roon for streaming Qobuz only as I sort this out. Thanks in advance for your help. 

 

Any reason you are trying to avoid dither or NS? 

 

Removing Dither or NS adds distortion due to truncation and will affect SQ in a negative way (which why that is not even an option in PGGB). Also using Noise shaping instead of dither keeps the quantization noise low in the audible range and will help get the best out of 128bit or 256bit precision. 

 

Subjective impressions aside, objectively, the noise floor of 8fS at 64bits is similar to the noise floor at 16fS at 32 bits, but you also get the benefit of improved reconstruction accuracy at 16fS. If storage is your main constraint, I strongly suggest 16fS 32 bits with NS on. If you have been using dither, it may also explain why 8fS at 64 bits sounds similar to 16fS at 32 bits.

 

I believe some filters in HQP for DSD upsampling with PCM input, do it in two stages, the first stage being upsampling to an intermediate rate of 16fS. By using 16fS 32bit as input, you are also potentially skipping some processing in HQP (i.e. 8fS to 16fS).

 

[mpaulson540]

11 minutes ago, Zaphod Beeblebrox said:

Any reason you are trying to avoid dither or NS? 

 

Removing Dither or NS adds distortion due to truncation and will affect SQ in a negative way (which why that is not even an option in PGGB). Also using Noise shaping instead of dither keeps the quantization noise low in the audible range and will help get the best out of 128bit or 256bit precision. 

 

Subjective impressions aside, objectively, the noise floor of 8fS at 64bits is similar to the noise floor at 16fS at 32 bits, but you also get the benefit of improved reconstruction accuracy at 16fS. If storage is your main constraint, I strongly suggest 16fS 32 bits with NS on. If you have been using dither, it may also explain why 8fS at 64 bits sounds similar to 16fS at 32 bits.

 

I believe some filters in HQP for DSD upsampling with PCM input, do it in two stages, the first stage being upsampling to an intermediate rate of 16fS. By using 16fS 32bit as input, you are also potentially skipping some processing in HQP (i.e. 8fS to 16fS).

 

 

Yes, based on numerous past messages in this thread, I believed that using a PGGB 64 bit output file (no dither/no noise shaping) as a pre-processed file for HQPlayer was the preferred method. I further understood that by selecting a 64-bit output file in PGGB automatically bypassed both dither and noise shaping. I was just trying to find a way to create 64 bit PCM files for HQPlayer DSD256 conversion that didn't routinely exceed the 4gb Wav limitation.

 

I hope I am clear on my intended purpose and understand that you are recommending 16fs 32bit with noise shaping as a pre-processing pcm file for HQPlayer. Based on my recollection, this doesn't seem consistent with past discussions which has been confusing at best. 

 

Thanks for your quick reply, I will go back and look at past messages regarding this subject -  likely I misunderstood.

[austinpop]

3 minutes ago, mpaulson540 said:

 

Yes, based on numerous past messages in this thread, I believed that using a PGGB 64 bit output file (no dither/no noise shaping) as a pre-processed file for HQPlayer was the preferred method. I further understood that by selecting a 64-bit output file in PGGB automatically bypassed both dither and noise shaping. I was just trying to find a way to create 64 bit PCM files for HQPlayer DSD256 conversion that didn't routinely exceed the 4gb Wav limitation.

 

I hope I am clear on my intended purpose and understand that you are recommending 16fs 32bit with noise shaping as a pre-processing pcm file for HQPlayer. Based on my recollection, this doesn't seem consistent with past discussions which has been confusing at best. 

 

Thanks for your quick reply, I will go back and look at past messages regarding this subject -  likely I misunderstood.

 

Since I'm not an expert, I may be able to give you a layman's perspective. 

 

Consider this: your input file (let's say it's redbook) consists of 16-bit samples at 44.1 kHz (1fs). These are read in and stored as 256-bit numbers in memory. All the PGGB math is done at 256-bit precision, and the final result is a 16fs output array in memory, each sample contained in a 256-bit number.  If you could write this out at as a 256-bit 16fs file, you would not need to do any noise shaping. But anytime you go from a high precision number (256-bit) to a lower precision (say 64-bit), the loss of precision generates a kind of noise called quantization noise. And how you deal with this noise has an effect on SQ.

 

You could simply throw away the extra 192 (256-64) bits (this is called truncation), or you could do it a bit smarter (dither), or even smarter (noise shaping). Each method results in the noise having a certain shape: hence the term noise shaping. The PGGB noise shaper lowers the noise floor in the audible range, by essentially squeeezing it out to the ultrasonic frequencies.

 

Were it me, I would just test multiple ways, and see which I liked best, as an input to HQP:

• 64/16FS with NS or dither
• 32/16FS with NS or dither
• 64/8FS with NS or dither.

 

 

 

[Zaphod Beeblebrox]

42 minutes ago, mpaulson540 said:

 

Yes, based on numerous past messages in this thread, I believed that using a PGGB 64 bit output file (no dither/no noise shaping) as a pre-processed file for HQPlayer was the preferred method. I further understood that by selecting a 64-bit output file in PGGB automatically bypassed both dither and noise shaping. I was just trying to find a way to create 64 bit PCM files for HQPlayer DSD256 conversion that didn't routinely exceed the 4gb Wav limitation.

 

I hope I am clear on my intended purpose and understand that you are recommending 16fs 32bit with noise shaping as a pre-processing pcm file for HQPlayer. Based on my recollection, this doesn't seem consistent with past discussions which has been confusing at best. 

 

Thanks for your quick reply, I will go back and look at past messages regarding this subject -  likely I misunderstood.

I understand how you would get that impression from the past posts. PGGB has evolved over time and so has our understanding of what works best.

 

The early versions of PGGB did processing at 64bits and so there was no need for dither or NS when the output was set to 64 bits as there is no re-quantization or truncation involved. Some experiments were also done using PGGB with Chords HMS which did it's own dither and noise shaping, and some felt it worked best with noise shaping turned off in PGGB (though objectively it is less desirable).

 

With PGGB currently processing at higher precision, it no longer makes much sense to provide an option that does not use dither or noise shaping. Even at 64bit precision, some operations are done at 128 bits, which is why those options exists even if you set the precision at 64 bits.

 

I hope that clarifies things and yes, my recommendation is still 16fs/32 bits or 16fS/64bits.

[Miska]

1 hour ago, Zaphod Beeblebrox said:

I believe some filters in HQP for DSD upsampling with PCM input, do it in two stages, the first stage being upsampling to an intermediate rate of 16fS. By using 16fS 32bit as input, you are also potentially skipping some processing in HQP (i.e. 8fS to 16fS).

 

 

No, upsampling to 16x will just significantly increase CPU load for such cases. In two stage cases, first stage multiplier is always at least 8x or 16x depending on the filter.

 

So if your input is 16fs, then first stage output will be for example 16 x 16 = 256fs.

 

1 hour ago, Zaphod Beeblebrox said:

If storage is your main constraint, I strongly suggest 16fS 32 bits with NS on.

 

That will just force modulator to encode lot of useless noise and will also result in heavily increased ultrasonic noise in the DAC output without any improvement in audio band SNR which is limited if nothing else but Johson-Nyquist noise.

 

Noise floor of the actual content in audio band is limited by the recording and source content noise floor.

 

[Zaphod Beeblebrox]

Edit: Retracted.  Yes, that is what I meant too, the potential to avoid two stage PCM upsampling.

 

1 hour ago, Miska said:

That will just force modulator to encode lot of useless noise and will also result in heavily increased ultrasonic noise in the DAC output without any improvement in audio band SNR which is limited if nothing else but Johson-Nyquist noise.

We have been down this road before, and I do not see a point in rehashing it. There is a reason many here choose higher precision in PGGB and I understand you do not believe in reducing the noise floor in audible range beyond the DAC's analog noise floor. Also, with 64bit output we are talking of out of band noise in the -500dB or lower range (dithered or noise shaped).

 

@mpaulson540 Of course one solution is to make it a little easier for those who wish to use DSD modulators with PGGB upsampling, so for fun, I did a 2 stage upsampling 1fS -> 16fS followed by 16fS -> 512fS in PGGB at 256 bit precision in PGGB and followed it up by my own 7th order single bit modulator (512DSD) and the modulator also runs at 256 bit precision.

 

 

 

[Zaphod Beeblebrox]

1 hour ago, Miska said:

So if your input is 16fs, then first stage output will be for example 16 x 16 = 256fs.

So, if someone desires DSD256 output like @mpaulson540 mentioned, then a 16fS input would mean only a single stage of upsampling 16 x 16 = 256 would it not?

3 hours ago, mpaulson540 said:

Using 128bit precision, I'm not sure I can hear a significant audible difference between the two versions with DSD256 upsampling in HQPlayer. Even with my limited system/ears, I can easily hear a difference between the raw 44.1 Aiff file versus PGGB 128-384-64 in HQP

 

[Miska]

1 hour ago, Zaphod Beeblebrox said:

 

 

 

You can make that noise floor arbitrarily low by adding more and more FFT points (and averaging) since it will be distributed to across more FFT bins. So these kind of figures are totally pointless.

 

With couple of days long FFT you get down to thousands of dB "noise floor".

 

What matters in the end is what comes out of the DAC as analog signal. That is what I base my designs on.

 

And as necessary, HQPlayer calculations are not restricted to 256-bit or any other particular number of bits. Those are arbitrary precision using as many bits are needed for wanted end result. It can be 32768-bit or what ever as needed. So talking about number of bits is pretty moot.

 

P.S. I can see some 5th order distortion you have there.

 

[Miska]

43 minutes ago, Zaphod Beeblebrox said:

So, if someone desires DSD256 output like @mpaulson540 mentioned, then a 16fS input would mean only a single stage of upsampling 16 x 16 = 256 would it not?

 

 

Two stages with second stage 1:1.

 

[Zaphod Beeblebrox]

54 minutes ago, Miska said:

Two stages with second stage 1:1.

So does the second stage 1:1 of PCM upsampling involve any additional CPU usage or filtering or is it just pass through?

 

55 minutes ago, Miska said:

You can make that noise floor arbitrarily low by adding more and more FFT points (and averaging) since it will be distributed to across more FFT bins. So these kind of figures are totally pointless.

 

With couple of days long FFT you get down to thousands of dB "noise floor".

All FFTs I do are based on 1Hz bin (FFT length is the same as the sample rate) and typically averaged over 5 seconds. It is still valid for comparisons as long as signals being compared are of the same length and same FFT and windowing are used. 

 

P.S. FWIW, I see you used RASA and shared a similar plot here, you used 1kHz input, the only difference is I used 1kHz ( -180dB) + 6kHz (-301dB). No amount of long FFT or averaging is going to retrieve the -301dB signal if it is buried in noise. Not sure about your 5th order distortion comment though.

 

 

 

[Miska]

2 hours ago, Zaphod Beeblebrox said:

So does the second stage 1:1 of PCM upsampling involve any additional CPU usage or filtering or is it just pass through?

 

It is the same filter, but just input and output at the same rate. Same for example if you go from 192k PCM source to 192k PCM output. If the filter cannot be run for that case, HQPlayer will refuse to play. So for example the apodizing function still works as intended.

 

 

One important fundamental thing to understand about noise-shapers is that given sample rate X and word length Y, the amount of noise is constant. With noise shaper you can move the noise around, but it won't disappear anywhere. So anything you take out from frequency A will appear at frequency B.

 

For DAC output the lowest possible noise level is ultimately limited by the analog world. So noise you take out from beneath the analog world limitations cannot exceed base level of noise set by laws of physics, but it can still appear elsewhere where it is higher.

 

So more you push down the audio band digital noise floor, more the noise appears elsewhere.

 

Example is running PGGB doing noise-shaping to 20-bit output vs HQPlayer doing 20-bit noise-shaping to Holo R2R ladder:

 

 

2 hours ago, Zaphod Beeblebrox said:

the only difference is I used 1kHz ( -180dB) + 6kHz (-301dB)

 

Which won't appear on any source content... I'm more interested about behaviour with 0 dB clipped signals which is real world example for 90+% of RedBook content.

 

[Zaphod Beeblebrox]

1 hour ago, Miska said:

One important fundamental thing to understand about noise-shapers is that given sample rate X and word length Y, the amount of noise is constant. With noise shaper you can move the noise around, but it won't disappear anywhere. So anything you take out from frequency A will appear at frequency B.

You are preaching to the choir here.

 

1 hour ago, Miska said:

For DAC output the lowest possible noise level is ultimately limited by the analog world. So noise you take out from beneath the analog world limitations cannot exceed base level of noise set by laws of physics, but it can still appear elsewhere where it is higher.

 

So more you push down the audio band digital noise floor, more the noise appears elsewhere.

 

You have beaten that horse to death before. I am interested in keeping the quantization noise as low as possible in the audible range. To my ears (and many here) there are audible benefits to doing so, even if the DACs analog noise floor is way above. It is easy to design a noise shaper that behaves similar to what you have shown in your measurements, but I am not interested in doing so and there are already softwares such as HQP that do that. I do not see the point in you repeating the same arguments. Your design philosophy is different than mine and I am OK with it. I understand people have preferences.

 

1 hour ago, Miska said:

3 hours ago, Zaphod Beeblebrox said:

the only difference is I used 1kHz ( -180dB) + 6kHz (-301dB)

 

Which won't appear on any source content... I'm more interested about behaviour with 0 dB clipped signals which is real world example for 90+% of RedBook content.

No, of course -301dB signal will not appear in the source content. It is a way to illustrate the smallest signal that will be preserved after noise shaping. Setting aside the analog noise floor, in the digital domain, even if the original signal is say 16 bit accurate, the intermediate samples can have a higher resolution. Again, my design priorities are different.