Popular Post Miska Posted April 17, 2021 Popular Post Share Posted April 17, 2021 1 hour ago, ecwl said: I mean, after people commented that HQPlayer filters don’t sound like Chord’s or particularly Chord M-Scaler, HQPlayer eventually added their Sinc-M and Sinc-L filters to mimick the M-Scaler’s longer tap length filters. sinc-M was because people were asking for such number. I don't use it myself though. But M-Scaler does such only up to 16x output rate. While sinc-L does 16M taps to 256x output rate. Whole different thing to process 1 million taps at low 768 kHz than 16 million taps at 12.3 MHz. And yeah, there's undocumented unofficial way to tell HQPlayer to use more or less taps for sinc-M. So you can do 32M or 64M or whatever silly figure even at 50 MHz (1024x) rates or such, if you have enough CPU/GPU power. 1 hour ago, ecwl said: And now, we basically have a full-blown offline upsamples that can do many, many more taps, run at 32-bit (instead of 24-bit) with noise shaping. You don't need offline upsample to do 32-bit PCM. HQPlayer can do 32-bit noise-shaped output on the fly. It could as well do 64-bit noise-shaped PCM if you can just find a DAC to support such. (and USB Audio Class is not fit for it either) 1 hour ago, ecwl said: And then when people still say M-Scaler sounds different and then Rob Watts mentioned that he doesn’t dither and uses noise shaping for M-Scaler, HQPlayer then added the LNS15 noise shaper. HQPlayer had NS4, NS5 and NS9 noise for maaany years before M-Scaler existed. LNS15 noise shaper was more recent addition. 1 hour ago, ecwl said: Call it piracy. Or call it Imitation is the Sincerest Form of Flattery. Chord digital filters have pretty average about 120 dB stop-band attenuation which equals to about 20-bit reconstruction precision. While I prefer million times higher, 240 dB stop-band attenuation which equals to about 40-bit reconstruction precision. And less than 0.1e-8 dB pass-band ripple. And in addition, sinc-M is apodizing filter while Chord's WTA is non-apodizing. So there is not much similarity except number of taps (which is pretty meaningless figure). Let's see when Chord will get anywhere near the performance... 1 hour ago, ecwl said: 1) HQPlayer did not have Sinc-M or Sinc-L long tap length filters until long after M-Scaler came out Yes it had, for example closed-form-M and closed-form-16M (16 million taps), and so on. But I considered number of taps pretty pointless figure so was not (and still I'm not) talking much about tap lengths. Especially because HQPlayer is not for any fixed output rate like 16x or similar, unlike M-Scaler. Instead it can do various different conversion ratios, including ones that are not multiples of the source sampling rate. Such things usually affect number of taps, so quoting a single figure is not sensible. 1 hour ago, ecwl said: 2) HQPlayer did not use noise shaping for 16fs upsampling with LNS15 as an option until a couple months after Rob Watts mentioned on Head-Fi forum that he doesn’t dither and uses noise shaping after 16fs upsampling Oh yes it certainly did, already about 10 years ago. NS4 and NS9 were introduced in January 2011. And those have never been limited to 16x rates. 1 hour ago, ecwl said: So while the IP is in public domain, Jussi took the easy way out and took Rob Watts tuning and incorporated it into his software without giving any credits to Rob Watts Which tuning are you talking about? Can you explain what I should give credit for? Some number of taps? While the taps I have are way much better than the ones created by Rob Watts. Since HQPlayer has been doing upsampling since 1998 and those noise-shapers instead of TPDF and shaped dithers since 2011, I would counter argument that Chord is just doing poor copy of what HQPlayer has been doing doing without giving any credits to HQPlayer. pavi, blue2, luisma and 14 others 10 5 1 1 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted April 19, 2021 Share Posted April 19, 2021 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... ray-dude 1 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted April 19, 2021 Share Posted April 19, 2021 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. Dev 1 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted April 19, 2021 Share Posted April 19, 2021 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. Zaphod Beeblebrox 1 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Popular Post Miska Posted April 21, 2021 Popular Post Share Posted April 21, 2021 Sending 32 bit to Holo Audio DACs will just result in last 8 bits being truncated (thrown away). The USB interface even reports that it is 24-bit in 32-bit sample container. HQPlayer can auto-detect this on Linux too. But 20-bit recommendation combined with NS5, NS9 or LNS15 noise shaper is based on measurements. Sending 24-bits there will just significantly increase distortion of especially low level signals and linearisation effect of noise shaper designed for this purpose is just lost because the conversion ladder doesn't have enough precision. Correct way to come up with number of DAC bits is to measure the DAC's analog output. (I have a reason why I have invested tens of thousands of Euros on measurement gear) kennyb123, blue2, Nikko1960 and 3 others 4 2 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted April 21, 2021 Share Posted April 21, 2021 1 hour ago, Johnseye said: If the 20 bit recommendation was based on measurements with NS9 or LNS15 then could it be different for PGGB? No, it is based linearity measurement of the DAC. And linearisation performance has been verified with my noise shapers designed for that particular purpose. I don't know if the noise shaper in PGGB can linearise the DAC with any setting, it depends on how it has been designed. That would need to be measured from the DAC output. Without such linearisation, for example with 24-bit TPDF dithered input, you have quite a bit of distortion on low level signals because the R2R ladder is not accurate enough. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted April 21, 2021 Share Posted April 21, 2021 24 minutes ago, Zaphod Beeblebrox said: Using lesser bits leads to more quantization error, so when recommending 19 bits or 20 bits for a 24 bit DAC, what is happening is the last 4 or 5 bits are zeroed out and not being used to avoid any distortions they may introduce. Even with 16-bit input (which you can do for example from macOS at 1.5M), with suitable noise-shaper the noise floor is flat to >100 kHz. So from 100 kHz bandwidth analog measurement you wouldn't be able to tell if the input is 20 or 16-bit because analog noise dominates. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted April 21, 2021 Share Posted April 21, 2021 Just now, Zaphod Beeblebrox said: Agreed, PGGB can noise shape to 12bits. OK, I support anything from 8 to 32 bits output. But where the analog noise floor boundary is crossed depends on combination of DAC and particular noise shaper. Best way to figure out is to measure. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted April 21, 2021 Share Posted April 21, 2021 36 minutes ago, sledwards said: Currently, I am using HQPe to feed upsampled PCM to my HOLO May DAC and am using digital volume control since I have no preamp in the chain. My question is, have any of you experienced a noticeable degradation in sound quality using PGGB with digital volume control vs a preamp volume control? Noise-shaping needs to be the last thing before output. So if you use HQPlayer volume, you need to have noise-shaping at HQPlayer side and you are better off doing 64-bit float output from PGGB. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted May 3, 2021 Share Posted May 3, 2021 2 hours ago, dmance said: In 2019 I prodded Jussi L. to push the envelope with his HQPlayer PCM filters and noise shapers to meet or exceed MScaler sound quality. His 2M tap Sinc-L filter and 15th order LNS15 noise shaper then became my reference for up-sampling. You are anyway better off with poly-sinc-ext2, sinc-S or sinc-M... Because sinc-L is non-apodizing. Note that sinc-M and sinc-L are totally different kind of filters, with nothing in common. Difference in number of taps between sinc-M and sinc-L is irrelevant detail. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted May 15, 2021 Share Posted May 15, 2021 On 5/14/2021 at 12:16 AM, ambre said: could only sent 32 bit to 16 bits PCM and SDM wasn’t available on macOS NAA DoP enabled as SDM Pack in HQPlayer settings? Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted May 19, 2021 Share Posted May 19, 2021 5 hours ago, austinpop said: I was under the impression that the Rossini would bypass the internal filters when presented 24/8FS. Isn’t this effectively what happens if preceded by the dCS Upsampler? It is very unfortunate if such expensive devices cannot run digital filters higher than 8fs, because they anyway need much higher sample rate for the modulator. Which would likely mean they do same as most DAC chips, meaning ~16x - 32x oversampling using sample-and-hold (IOW, just repeating the same sample N times). I know Chord runs simple IIR and then linear interpolation after WTA1 stage. They still don't have enough processing power... With HQPlayer I of course run full proper digital filters up to the final modulator rate, typically 256fs - 1024fs these days. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted May 27, 2021 Share Posted May 27, 2021 3 hours ago, happybob said: who use a DAC that sounds best with DSD Should be any DAC that is able to convert DSD natively to analog... Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted May 27, 2021 Share Posted May 27, 2021 8 hours ago, Zaphod Beeblebrox said: Assuming the same DAC being incapable of sounding as good or better with PCM. So far all delta-sigma DACs on the market I've seen make shortcuts for PCM processing. DSD is only way to run proper digital filters up to modulator rate and also work around on-chip modulator deficiencies. 8 hours ago, Zaphod Beeblebrox said: Also assuming said DAC is a single bit delta sigma DAC and not a multi-bit delta-sigma DAC or has a pure single bit delta sigma mode that sounds superior to other modes that may be available on the same DAC. No, multi-bit delta-sigma doesn't make it any better than single-bit. Best example are DACs with TI's chips that work absolutely best in DSD mode. Same goes for recent AKM chips that have DSD Direct mode. Also DACs like Chord Mojo have so inadequate multi-bit modulator, that they would benefit from direct DSD conversion if they would have such. It is just that their DSD-to-PCM conversion is even more inadequate than their PCM processing. So you are stuck to just playing with digital filters but no way of getting around the modulator. Even with ESS Sabre you can get around deficiencies of the PCM side by using DSD inputs even though it doesn't have direct mode. The DSP just gets so much simplified for DSD inputs. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted May 27, 2021 Share Posted May 27, 2021 4 minutes ago, Zaphod Beeblebrox said: It depends on the DAC implementation It is pretty easy in a way that there are only few DAC chip architectures. I have measured quite a bunch and continue doing so. 4 minutes ago, Zaphod Beeblebrox said: the quality of DSD or PCM upsampling Certainly... 4 minutes ago, Zaphod Beeblebrox said: listening preference and playback chain I have objective approach, so listening preferences don't affect this. Zaphod Beeblebrox 1 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted June 30, 2021 Share Posted June 30, 2021 2 hours ago, StreamFidelity said: I used a different software to remaster some CDs with 134 million tabs. This high number cannot be achieved with real-time processing. Why not? Whether it makes sense is another question... The delay just becomes annoyingly high, because you have 67 million sample lead-in and lead-out. Unless you run at DSD1024 rate where it is then just a bit over one second. StreamFidelity 1 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted July 1, 2021 Share Posted July 1, 2021 18 hours ago, Zaphod Beeblebrox said: Real time processing with 134million taps and more is easily possible, I have benchmarked PGGB-RT SDK with up to 1B taps in Realtime. Though for most streamed audio 256M taps will be plenty and if done right, after a few seconds of startup delay (5-15 seconds), gapless playback is possible too. I was able to do this on my Mac M1 pro. By definition your startup delay (lead-in) is half of the filter length if the filter is linear phase. Otherwise you are truncating your transient/step-response. 1B taps at 768 kHz means having 651.4 seconds lead-in delay. And 256M taps is 166.67 seconds lead-in delay. Try with a 44.1 kHz track that has dirac pulse, or square step, as second sample and another one at the sample before the last one. First and last sample being 0. Then look at resulting time and frequency domain responses. If your filter pre-ringing is truncated, you are truncating your transient responses. For example try this file: https://www.signalyst.eu/test/dirac2.wav Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted July 1, 2021 Share Posted July 1, 2021 21 minutes ago, Zaphod Beeblebrox said: If you are referring to not throwing away and keeping the first 1/2 filter length worth of samples (after convolution) and just treat the successive tracks as one continuous stream, I do not like that approach either and I had already explained why in an earlier discussion. This would result in using samples form disjoint points in time and is not optimal either. I prefer to process one full track at a time, just the way PGGB desktop does. That is what should happen if you process one track at the time. It should become half filter length longer at the beginning and end. Otherwise you are truncating transients that happen before and after half filter length to the track. If you process entire album at once, then only beginning of first track is half filter length longer and end of last track is half filter length longer. But then you need to accept that transient response gets broken for half filter length if you seek, or begin playing anywhere else than beginning of the first track. For typical filters this time window would be only couple of milliseconds. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted July 1, 2021 Share Posted July 1, 2021 17 minutes ago, Zaphod Beeblebrox said: If you process the whole album as one then you are assuming all the tracks are truly continuous in time which is rarely true and we don't even know if it is an album or a playlist with unrelated material. One reason why HQPlayer makes a difference between album and playlist. Most albums are gapless these days. If you are reading a CD you can actually know if it's a case or not. But I have only very few CDs where it is not the case. 19 minutes ago, Zaphod Beeblebrox said: Then you would have to accept that you are reconstructing your new samples borrowing samples from unrelated material when you are near the end of a track or beginning of the next one, that could not be possibly good either. This is what MScaler does too, since it cannot know where a track boundary is. Or where someone seeked or skipped a track unless sampling rate changes. This is advantage of player applications since they can have this information. 21 minutes ago, Zaphod Beeblebrox said: I have tried both approaches, and settled on processing on a per track basis based on both subjective listening tests and a over all better user experience. Yeah, then the trade-off is that you need to make the track filter length amount of longer than it originally was to avoid truncating transients near beginning and end. Longer the filter, longer that goes. 22 minutes ago, Zaphod Beeblebrox said: This thread wont exists if everyone is happy to just settle for 'typical' filter 😏 Yes, for me, the interesting thing is to have as few taps as possible to minimize amount of ringing and transient spread and still have optimal frequency domain behavior too without leakages. IOW, optimize both time and frequency domain at the same time, although the have 1/x relationship. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted July 29, 2021 Share Posted July 29, 2021 10 hours ago, Zaphod Beeblebrox said: letting SRC-DX truncate 32bit to 24bit will till be OK Truncation generates distortion, how can that be OK? You always need to dither or noise shape to avoid generating distortion, no matter if the output is 24-bit, 32-bit or something else. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted July 29, 2021 Share Posted July 29, 2021 3 hours ago, Zaphod Beeblebrox said: Thanks for chiming in (again). You have quoted me completely out of context. Of course truncation is never a good idea (duh!) Some context: I was addressing a very specific question where he wanted to know pros and cons of using 24bit vs 32bit (with noise shaping/dithering turned off) going into SRC-DX, and yes he is aware that this is not ideal. In this case, allowing SRC-DX to truncate 32 bit to 24bit will be OK (SRC-DX is USB to dual BNC converter and outputs 24bits, it does no other processing or dithering). He also wanted to use the same files with Roon (and the additional resolution of 32bit files will be helpful for downsampling) Yes, I understand this, but in my opinion it is not OK to let SRC-DX truncate 32-bit to 24-bit, as it will add distortion. This was the reason why I commented on the topic. For that purpose, there should be two sets of files, one dithered to 24-bit and another dithered to 32-bit (for Roon). 3 hours ago, Zaphod Beeblebrox said: Some more context: His SRC-DX feeds into the dual BNC input of Mscaler. Mscaler does not have a true pass through mode and it applies -3dB gain and noise shapes any input it receives, and most have found using noise shaped signal adds harshness due to the additional noise shaping it does. This is the reason he had to turn of noise shaping in PGGB. PGGB automatically dithers or noise shapes based on output samplerate. Turning it off applies neither dithering or noise shaping as the output is designed for bit-perfect playback into the DAC. But in use cases such as this, it would be good to have an option to just apply dither to aid further processing. I do plan to add an option to add dither without any noise shaping in the next release to address a few unusual use cases. If this option existed, I would have recommended using 24bit dithered output. That was my point, output should be at least TPDF dithered, regardless of output resolution. Be it 24-bit or 32-bit, if noise shaping is not applied. Zaphod Beeblebrox 1 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Popular Post Miska Posted August 1, 2021 Popular Post Share Posted August 1, 2021 55 minutes ago, ASRMichael said: @Zaphod Beeblebrox can I ask why do 24bit DACs accept a 32bit signal? Especially if it’s being truncated to 24bits? What is the DACs designer thinking? Not him, but it is because 24-bit data is 3 bytes long and very inefficient to deal with in computers and micro-controllers used for USB interfaces, since sample size is not power of 2. In addition that means that buffer boundaries don't align with bus width and thus causes problems for DMA transfers. 32-bit data is 4 bytes long and thus allows efficient handling and proper DMA transfers. There are some USB interface implementations that support 24-bit sample sizes, but most implementations like XMOS use 32-bit sample size for above reasons. DAC can report it's true resolution even if it uses 32-bit sample size for transfers. True resolution could be for example 20 or 18-bit which are not even possible as transfer unit size (such as old Burr-Brown or Analog Devices R2R chips). WASAPI on Windows supports this information, ASIO doesn't. I've added support for this into Linux kernel and it is now in recent mainline Linux kernels too. I2S is also 32-bit, and then the number of actual bits used to handled outside of I2S. lwr, kennyb123, happybob and 1 other 1 3 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Popular Post Miska Posted August 1, 2021 Popular Post Share Posted August 1, 2021 37 minutes ago, ASRMichael said: Thanks. So I have a pair of Burr Brown PCM1794A. This DAC is 24bit but accepts 32bit. Should I avoid truncating from 32 to 24bit? Yes, definitely. Truncation always generates distortion. You should dither/noise-shape to 24-bit for it. lwr and ASRMichael 2 Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted October 3, 2021 Share Posted October 3, 2021 3 hours ago, davide256 said: FLAC does not support 705/768. FLAC is max 384k and max 24-bit. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Miska Posted January 4, 2022 Share Posted January 4, 2022 9 hours ago, kennyb123 said: Not good to allow oneself to be biased by other’s claims - especially if the claims are theoretical in nature. Math of this stuff is pretty clear. And I did run test to confirm what I already knew. Signalyst - Developer of HQPlayer Pulse & Fidelity - Software Defined Amplifiers Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now