Extreme filtering software upscaling

[Ittaku]

Just now, rmpfyf said:

 

I’d vote Ethernet then. Getting a PC to handle anything else as an input is money, and you’re effectively asking a ‘second’ PC to act as an interstate at any rate. Nothing else is going to be as quick, robust or inexpensive.

 

Plenty of similar dual PC audiophile rigs do similarly, some using fibre links though IMHO not necessary.

At the moment I'm wedded to the essential DSP component between my PC and my DAC unfortunately, and it's only spdif between those last two components at the moment. I'd have to look for a completely different crossover and room correction solution instead. To be honest, the sound improvement from my DSP room correction is about 100,000 times more substantial than the upscaling so I have to admit I'm losing steam in terms of interest for this project. My DAC also doesn't really accept more than 192 via coaxial so it's only one step higher than my current sample rates, unless I buy the network rendering module for the DAC and completely revamp my entire system, offloading the DSP to another PC solution... This is possible, but again I need to weigh just how much benefit I'll get from upscaling further versus the massive increase in inconvenience. I may just shelve the idea completely shortly...

[davewantsmoore]

1 hour ago, Ittaku said:

I'm considering all possible PC options for a generalised solution; not just for my use case. Ideally it should have usb, coax and optical in, and the same outputs. I2S has its place but those three will cover 99% of the hi-fi world. Though for now I should probably be concentrating on my own...

To me, having the computer participate in any type of non-packetised data stream seems like an iffy idea in general..... so I'd be looking at ethernet, firewire, or USB ... and converting on the other end (if it were necessary).

[Ittaku]

Just now, davewantsmoore said:

To me, having the computer participate in any type of non-packetised data stream seems like an iffy idea in general..... so I'd be looking at ethernet, firewire, or USB ... and converting on the other end (if it were necessary).

Well I'd be turning it back into packet data and buffering it to work with it, but anyway I've all but lost interest.

[rand129678]

On 29/01/2019 at 9:31 PM, Ittaku said:

A bit of calculation suggests that the way RW targets 16 bit regeneration requires 1 million taps

Does that ~1M taps calc apply only for a PCM 16bit/44.1kHz source file?

 

Does the calc (number of taps required for 16 bit regen) change for double the sample rate, i.e. PCM88.2kHz source file? Does the number of taps required just halve or it's not so straight forward?

Edited February 4, 2019 by Music2496

[Ittaku]

Just now, Music2496 said:

Does that ~1M taps calc apply only for a PCM 16bit/44.1kHz source file?

 

Does the calc (number of taps required for 16 bit regen) change for double the sample rate, i.e. PCM88.2kHz source file? Does the number of taps required just halve or it's not so straight forward?

In my case, the number of taps is actually static, so whether you're going from 16/44 to 24/88 or 24/704 the number of taps remains (78M). This is completely different to Chord's Mscaler the way they've implemented it, where the number of taps is proportional to the amount of upscaling. You need to go 16x upscaling to get their 1M taps.

[Guest rmpfyf]

32 minutes ago, Ittaku said:

In my case, the number of taps is actually static, so whether you're going from 16/44 to 24/88 or 24/704 the number of taps remains (78M). This is completely different to Chord's Mscaler the way they've implemented it, where the number of taps is proportional to the amount of upscaling. You need to go 16x upscaling to get their 1M taps.

You said you’d lost interest, you lied  

[Ittaku]

Just now, rmpfyf said:

You said you’d lost interest, you lied  

Oh I mean lost interest in taking the hardware solution any further. I'll continue to upsample everything with this approach whenever I have 44/48 material.

[Nada]

55 minutes ago, Ittaku said:

Well I'd be turning it back into packet data and buffering it to work with it, but anyway I've all but lost interest.

Your not allowed to until you develop a Foobar dsp for running SOX with a real-time 76,000,000 tap filter.

 

While Im waiting is it worth trying HQPloyer with its million tap SINC?

[Ittaku]

Just now, Nada said:

Your not allowed to until you develop a Foobar dsp for running SOX with a real-time 76,000,000 tap filter.

 

While Im waiting is it worth trying HQPloyer with its million tap SINC?

Hah.

 

I don't see why not? Though when I tried 1 million it was nowhere near as big an improvement and too subtle. I think Chord get away with "only" 1 million because of their approximation algorithm (WTA). We don't have their top secret algorithm for that.

[legend]

At his request, I have given your upsampled files (and original) of my Telarc-Kamen recording to the tympanist in the Tasmanian Symphony Orchestra (hope you don't mind).   He is going to also compare with the HQPlayer. 

 

This afternoon I upsampled the recording to 352k with Audacity on its 'very high' quality that also uses SoX but although slightly better it was not nearly as good as your 88k version let alone your 352k version.  I guess Audacity does not use enough taps, though I can find no information on this.

[Ittaku]

14 minutes ago, legend said:

At his request, I have given your upsampled files (and original) of my Telarc-Kamen recording to the tympanist in the Tasmanian Symphony Orchestra (hope you don't mind).   He is going to also compare with the HQPlayer. 

 

This afternoon I upsampled the recording to 352k with Audacity on its 'very high' quality that also uses SoX but although slightly better it was not nearly as good as your 88k version let alone your 352k version.  I guess Audacity does not use enough taps, though I can find no information on this.

No of course I don't mind. I'll happily convert files for other people too if they want to try it.

 

SOX VHQ is 95% bandwidth (versus 99.99996%), 175dB rejection (vs 204) and 532 taps.

sox DBUG rate: fir_len=533 dft_length=2048 Fp=0.9115101289311444 Fs=1.000000 Fn=2.000000 att=174.597 2/1

compare with

DBUG rate: fir_len=77432065 dft_length=134217728 Fp=0.9999992860029445 Fs=1.000000 Fn=2.000000 att=204.021 2/1

Edited February 4, 2019 by Ittaku

[Guest rmpfyf]

1 hour ago, Ittaku said:

No of course I don't mind. I'll happily convert files for other people too if they want to try it.

 

SOX VHQ is 95% bandwidth (versus 99.99996%), 175dB rejection (vs 204) and 532 taps.

sox DBUG rate: fir_len=533 dft_length=2048 Fp=0.9115101289311444 Fs=1.000000 Fn=2.000000 att=174.597 2/1

compare with

DBUG rate: fir_len=77432065 dft_length=134217728 Fp=0.9999992860029445 Fs=1.000000 Fn=2.000000 att=204.021 2/1

Don't let it go; it's a nice achievement. Surely there's got to be a way to continue it into something ongoing.

[Ittaku]

2 minutes ago, rmpfyf said:

Don't let it go; it's a nice achievement. Surely there's got to be a way to continue it into something ongoing.

Ta. I'll stick to the software side though since that's really my domain.

[tripitaka]

I am so glad that threads like this exist,  though I doubt I'll be implementing anything very soon, as my dear little RPi wont be up to the task. 

I find it reassurring somehow that the ultimate 'limits' of audio reproduction are being explored and defined in the public domain... and may even be $ attainable for the common man.

Thank you @Ittaku !!

[Ittaku]

By the way, Ive reworked the 500 million tap filter to work properly and it takes 40 minutes to filter a 4 minute track, and needs about 14gb ram. I'm not sure my previous comparison was valid based on some bugs I had in the earlier code so I'll repeat the audition tomorrow to see if it sounds better. I won't be comparing many files though thanks to how slow it is...

[tripitaka]

18 minutes ago, Ittaku said:

By the way, Ive reworked the 500 million tap filter to work properly and it takes 40 minutes to filter a 4 minute track, and needs about 14gb ram. I'm not sure my previous comparison was valid based on some bugs I had in the earlier code so I'll repeat the audition tomorrow to see if it sounds better. I won't be comparing many files though thanks to how slow it is...

So if 500M turns out to be better after all, then we are back on the merry-go-round (which moves us into the billions?)!   Fingers crossed its worse hehe!

[Guest rmpfyf]

25 minutes ago, Ittaku said:

By the way, Ive reworked the 500 million tap filter to work properly and it takes 40 minutes to filter a 4 minute track, and needs about 14gb ram. I'm not sure my previous comparison was valid based on some bugs I had in the earlier code so I'll repeat the audition tomorrow to see if it sounds better. I won't be comparing many files though thanks to how slow it is...

 

Call Spotify, tell 'em you'll give punters a better deal than Tidal got with Meridian  

[Ittaku]

21 minutes ago, tripitaka said:

So if 500M turns out to be better after all, then we are back on the merry-go-round (which moves us into the billions?)!   Fingers crossed its worse hehe!

By what theory and my experimenting tells me, it can't be worse, but it's whether it's audibly better or not. Las time I tried it was not. 500m was chosen because of perfect impulse height at 24 bits resolution after filtering. We can't hear at that resolution but given my media is 24 bit I want to see... Chord chose a value of 1m because it corresponds with 16 bits but they also have special sauce when I only have brute force.

[Guest rmpfyf]

14 minutes ago, Ittaku said:

By what theory and my experimenting tells me, it can't be worse, but it's whether it's audibly better or not. Las time I tried it was not. 500m was chosen because of perfect impulse height at 24 bits resolution after filtering. We can't hear at that resolution but given my media is 24 bit I want to see... Chord chose a value of 1m because it corresponds with 16 bits but they also have special sauce when I only have brute force.

 

F the sauce... flex!!

[rand129678]

On 30/01/2019 at 6:40 PM, davewantsmoore said:

Remember how surprised 2L were that they needed 14bits to encode their content (and how it was the most they'd ever needed).

Could you share where 2L has said this? I've dug around but had no luck.

 

It wouldn't surprise me of course (14 bits is plenty of dynamic range) but I'd like to see 2L's comment about it...

 

Edited February 4, 2019 by Music2496

[rand129678]

31 minutes ago, rmpfyf said:

 

F the sauce... flex!!

Hilarious 

[legend]

11 hours ago, Ittaku said:

No of course I don't mind. I'll happily convert files for other people too if they want to try it.

 

SOX VHQ is 95% bandwidth (versus 99.99996%), 175dB rejection (vs 204) and 532 taps.

sox DBUG rate: fir_len=533 dft_length=2048 Fp=0.9115101289311444 Fs=1.000000 Fn=2.000000 att=174.597 2/1

compare with

DBUG rate: fir_len=77432065 dft_length=134217728 Fp=0.9999992860029445 Fs=1.000000 Fn=2.000000 att=204.021 2/1

If anyone else wants to try the track that @Ittaku kindly upsampled for me please PM - I have uploaded the files onto my website for easy download.  I don't regard it as piracy but a research exception in IP law.

 

The track is from the Cincinnati Pops Orchestra - Kamen: Robin Hood - and is from a Telarc 'finest recording' CD that has lots of dynamics and at times complexity.

[soundbyte]

I have downloaded the three files thanks to @legend .

 

One question are these files all level matched?

 

I seem to remember reading earlier in the topic that the original file was reduced by 2db(?) to enable upsampling.

 

If so, the original would need to be reduced by the same amount to enable fair comparison when playback is undertaken?

[Ittaku]

1 minute ago, soundbyte said:

I have downloaded the three files thanks to @legend .

 

One question are these files all level matched?

 

I seem to remember reading earlier in the topic that the original file was reduced by 2db(?) to enable upsampling.

 

If so, the original would need to be reduced by the same amount to enable fair comparison when playback is undertaken?

I have not touched his original file so I can't have lowered the volume on that one. For my own comparisons I always level matched. Should I upload a level matched original somewhere?

Edited February 5, 2019 by Ittaku

[Ittaku]

I did some further experimentation and compared the 500m to the 78m and whilst I initially thought I could barely make out a difference, ABX testing showed me I could not tell them apart blind, so it was all in my head. I went downwards as well and found the first noticeable difference was at about 15m, so my estimate around 30m as optimal probably wasn't far off. If I reduce the rejection to only 160dB (26dB below the noise floor of 24 bits so can have no effect any more), it comes down to "just" 25m taps, and the processing is very quick. This brings my final optimal minimum recommendation to 5 9s of bandwidth. This requires only minimal changes to the sox code to support, compared to the insane levels I mentioned previously. Here are my recommended settings:

 

sox -V4 input.flac -b 24 output.flac vol -2dB rate -b 99.999 -d 32 -R 160 88200

 

Note these are my recommendations for upscaling to just double the sample rate. Also this is based on my own auditioning and your hearing may be better than mine. I don't know if it's audibly better to use more taps at higher sample rates either. I'll see if I can rationalise the code changes into a very small set that other can apply to sox themselves.

Edited February 5, 2019 by Ittaku