![sin xtr hqplayer sin xtr hqplayer](https://www.signalyst.com/images/network_streaming.png)
![sin xtr hqplayer sin xtr hqplayer](https://1.bp.blogspot.com/-qPcz4tqd0wU/XF1IwyyuxNI/AAAAAAAASXo/zfV0667417EAqLuR6gANlng6TbPt3LjlwCLcBGAs/s1600/Settings%2B-%2BCropped.png)
Music IZZ-Album-Don't Panic-listened entire album Roon>wifi>digione>coax>mscaler>dualCoax>H2>utopia HQP filter was poly-sinc-xtr (as recommended to be the closest to Chord), no dither, 705/768khz
![sin xtr hqplayer sin xtr hqplayer](https://hqplayer.cn/wp-content/uploads/2020/07/微信图片_20200731181212.jpg)
This guy Keith Howard seems to have done it 10 years ago: But obviously I do not have the knowledge to judge it. Secondly, I suspect that besides Rob optimizations that optimize speed and are only necessary for real time as in MScaler, Rob filter likely has other details that are crucial for the SQ result (independently of speed) and that come from all his years of research and experience, and specially his genius. But I would make two points:įirstly, I agree with you, why doesn't anybody do it? I am not convinced by HQ Player from what I read (I have not tried it yet because it does not run on Windows 7).
#SIN XTR HQPLAYER SOFTWARE#
Keith suggests it could be even better than MScaler, because it does not need simplifications and optimizations, just brute force to do the ideal process.Īnother thing he says is that programming the software is much simpler than the FPGA (which I think we can all agree), moreover because the FPGA real time operation requires the genius Rob optimizations. I have only about 300 CDs, so about 3TB only.īut the big question is how does it compare to MScaler SQ wise. Size is no problem either: 1000 CDs = 600GB. And GPU cards have many parallel processors/cores, just like the FPGA.Įven if not real time it is fine with me, it can take its time, it only has to be done once. That 300x would be smoked using a current GPU card. So, 300x real time using a 10 year old single core desktop computer, not using a GPU, and most likely not using speed optimized code. For 4× oversampling, the processing (which uses 64-bit floating point arithmetic and generates a 24-bit output WAV file) took 295 seconds – over 300× real time – running on a single processor core of my ageing desktop computer.
![sin xtr hqplayer sin xtr hqplayer](https://3.bp.blogspot.com/-quNEUXTu5T8/XF9gw8nOOyI/AAAAAAAASYw/18M-XU2Ui9QwI4yyaxKfVmmKcCzAvbcdACLcBGAs/s1600/HQPlayer%2BResampler%2BDFCs.png)
#SIN XTR HQPLAYER CODE#
To show you an example, I ran the code using a short (0.98 second) mono, 44.1kHz/16-bit WAV file containing a single note played on a harpsichord. Once you have the file, it can be used as a reference against which to audition others generated using finite-length interpolation filters of different designs.
#SIN XTR HQPLAYER FULL#
But, like I say, it’s easy, it’s cheap, and it allows you to generate and listen to a file that’s been oversampled using full sinc interpolation, in which respect it’s even better than the M Scaler. The problem is, the program takes ages to run with anything longer than a very short audio file because it requires the calculation of (U-1) × N2 sin(x)/x values, where U is the oversampling factor and N is the number of samples in the file. I first wrote a software utility to do this over 10 years ago – and compared to FPGA programming it’s an absolute doddle. That’s to perform sinc interpolation offline, in software. But there is another way, which is a lot cheaper than acquiring a collection of Chord hardware and much easier than taking the very major step of programming an FPGA.