Chord Electronics Owners & Discussion Thread

[davewantsmoore]

21 hours ago, Eggcup The Daft said:

"though some would insist it's guaranteed to"

You will need a lot of time and patience when going down that road.

Indeed.

 

Given a looooong enough filter it *is* guaranteed to  (says Chord themselves,  as shocking as this is to some) .... but it isn't very practical.     Implementing it in the real world, is a case of "choose your compromise", which eventually comes down to listening tests (which is where RW spent all the time).

 

[davewantsmoore]

12 hours ago, Ittaku said:

78 million taps

Without any multithreading, or (I would assume, depends on your compiler) any sort of deep instruction set optimisation.

 

It's possible you could times these numbers by anything from 10 to 100.... depending on what year/ix CPU this is.

[Ittaku]

2 minutes ago, davewantsmoore said:

Without any multithreading, or (I would assume, depends on your compiler) any sort of deep instruction set optimisation.

 

It's possible you could times these numbers by anything from 10 to 100.... depending on what year/ix CPU this is.

Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz (x6/12HT)

 

Ram is the rate limiting thing at the moment. Those filters require 4GB, and the software doesn't malloc in a way to make the most of 64 bit addressing. See the other thread I started for more details.

Edited January 29, 2019 by Ittaku

[Guest Eggcup The Daft]

1 hour ago, davewantsmoore said:

which eventually comes down to listening tests

Is there no objective measurement available in any of this? Are there not mathematical proofs in here as well? I had assumed that maths played a large part of RW's work here from what I've read.

 

When something "comes down to listening tests" alarm bells go off in my head.

[rocky500]

43 minutes ago, Eggcup The Daft said:

When something "comes down to listening tests" alarm bells go off in my head.

Funny that, as when it ultimately comes down to your listening pleasure, I would of thought listening tests are a fine way.

 

I thought I read RW say it starts to get hard to measure down to these small scales. 

I'm sure he uses tons of ongoing measurements in all his designs with the added listening tests to finalize his designs.

Edited January 29, 2019 by rocky500

[Guest Eggcup The Daft]

14 minutes ago, rocky500 said:

Funny that, as when it ultimately comes down to your listening pleasure, I would of thought listening tests are a fine way.

 

I thought I read RW say it starts to get hard to measure down to these small scales. 

I absolutely agree... for us as users.

 

For a manufacturer or designer, I'd hope for some reason for their decisions - either some kind of blind testing (please, let's not go THERE again!) or at least listening between options with theoretical or measured support to a standard.

 

Listening has to play a role and may well be involved in decision making, even if only as a sanity check. RW seems to me a guy that does the other stuff as well.

 

 

[Guest]

In regards to the math, in one of those Rob Watts lectures, he mentions that the mathematics are an inarguable fact In regards to turning the data on the cd back to the original analog wave form. 

[davewantsmoore]

5 hours ago, Ittaku said:

Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz (x6/12HT)

 

Ram is the rate limiting thing at the moment. Those filters require 4GB, and the software doesn't malloc in a way to make the most of 64 bit addressing. See the other thread I started for more details.

That's a powerful processor, but doesn't have some of the efficiency gains on later instruction sets.... my (fairly rudimentary) understanding is there's ways you could do this which wouldn't need such a large amount of memory.

 

4 hours ago, Eggcup The Daft said:

Is there no objective measurement available in any of this?

Of course ..... but when the measurement says changing something improves one part, but makes another worse .... then you have to choose which you "like" better.

 

Edited January 29, 2019 by davewantsmoore

[davewantsmoore]

3 hours ago, Sime V2 said:

In regards to the math, in one of those Rob Watts lectures, he mentions that the mathematics are an inarguable fact In regards to turning the data on the cd back to the original analog wave form. 

The mathematics of the sampling theorem are inarguable.....   but they involve the use of an infinitely long function, and infinity doesn't exist in the real world.

 

The whole idea here is to use a relatively long representation of the function.... and then compensate for the fact you are using a finite representation of the function.

[Guest Eggcup The Daft]

27 minutes ago, davewantsmoore said:

Of course ..... but when the measurement says changing something improves one part, but makes another worse .... then you have to choose which you "like" better.

If you're a manufacturer or working for the same, you may need to choose what will make the most money, or at least sufficient... that's different. It's different from choosing the "best" workable option inside the budget, sometimes, as well.

 

 

[CN211276]

I have found this thread informative and have now had the chance to hear the Mscaler with my Qutest. I was not all that impressed at the dealers but it was a different matter when I took it home on loan. The sound stage took on a new dimension in terms of both width and depth with better defined bass. I cant be without it and have one on order. My system is NVA with semi omnidirectional speakers. My only issue concerns video as I was not able to successfully connect it to my Sky+ box.

[Guest]

@CN211276 my system is a completely different one since. Brilliant machine. 

[Ittaku]

I think @Sime V2was right, Chord are really onto something with this. It may well be the missing link to make regular resolution digital reach its limits. Filtering close to the audible range has been the "problem".

[Guest]

@Ittaku just buy one, end the madness

[Ittaku]

28 minutes ago, Sime V2 said:

@Ittaku just buy one, end the madness

Won't work in my system optimally as you've seen.

[Guest]

Good review here

 

https://www.soundstageaustralia.com/index.php/reviews/255-chord-electronics-hugo-m-scaler-digital-upscaler

[Ittaku]

16 minutes ago, Sime V2 said:

Good review here

 

https://www.soundstageaustralia.com/index.php/reviews/255-chord-electronics-hugo-m-scaler-digital-upscaler

Interesting quote:

Quote

It’s within reason to have expected a USB output with provision for the full 768 kHz resolution to your DAC’s USB input, alas, that option is not present. I’m told this inclusion would have meant a significant delay to the M Scaler’s release date.

That suggests they did consider it, and perhaps may be in a future product? That would make it much more flexible with other brand devices, so perhaps we have been too hard on them being inclusive, but we'll see.

[legend]

Because I have other things to spend $7.5k on at the moment  (but fell in love with it when @Sime V2 brought it to my system) I have spent the last couple of weeks trying to investigate whether it is possible, and how well, to emulate it off-line. To start with the conclusion - I have not found it possible so far, though this may at least partly reflect limitations in my computing skills (unlike @Ittaku)!

　

I used the shareware 'sox' program that has the same sinc (sin/x) formulation to upscaling as does the M-Scaler. And because I don't have experience with C++ programming language (only Fortran from a long while ago) I used the Windows version of 'sox' that can be downloaded from https://sourceforge.net/projects/sox/files/sox/14.4.2/.

　

The sox.exe file runs in MS Windows command-line window. The 'rate' feature in sox contains its upsampling option with some sub-options. The most general command line I used is

sox -v 0.9 MusicFile.wav MusicFile-out.flac rate -v -L -s -a -b 99.7 352800

where -v 0.9 reduces the volume by 0.9 (approx 2 dB) to prevent clipping

MusicFile.wav is a ripped Redbook file at 44100 and 16 bits and must be in the same folder as sox.exe

MusicFile-out.flac is the upsampled file (created in the same folder as sox.exe)

The '-v' after rate specfies 'very high quality' upsampling (the highest choice allowed)

-L specifies linear phase (it can also be set M for minimum phase and I for intermediate phase)

-s specifies steep filter rolloff (and can be left out if not required)

-a allows aliasing at the cutoof frequency (and can be left out if not required)

-b specifies bandwidth

99.7 is the maximum badwidth allowed

352800 corresponds to 8x upsampling (the program fails with x16 upsampling).

　

An upsampling took about 30 secs for a 3 min MusicFile on my medium quality computer - with a AMD A6 5-core 2.60 GHz processor with 8Gb of RAM. The music was a mixture of classical, jazz and rock.

　

With all these independent variables it is difficult to try all permutations and combinations of them. However with the combinations I tried I did not like the sound quality of -s and -a so did not investigate them further.

　

In general I found the changes produced by my upsampling over the original Redbook file were obvious but fairly small using my Qutest DAC - and certainly much smaller than I remember given by the M-Scaler when it was upsampling x16 and using the dual SPDIF inputs to the Qutest (though also much less obvious at lower sampling rates).

　

I wonder if one 'problem' is that theQtest DAC upsamples all files to x16 so at least to some extent the Qutest overrides the effects of previous upsampling if this is lower than x16? With the M-Scaler I seem to remember its effects were also fairly small when its output was less than x16 and that dramatic (magic!) improvement in SQ seemed to mainly occur at x16 upsampling and so all the upsampling only occurs in the M-Scaler with its 1 million taps?

　

Certainly when I tried my upsampled sox files on my Project S2 DAC that I think does not itself upsample the effects of the sox upsampling seemed more pronounced (though the overall sound quality was not as good a the Qutest, not surprising given their price difference).

　

The other 'problem' may be that I am just using the 'very high quality' upsampling option in sox and even with extending the bandwith from its default value of 95% to 99.7% and the rate to 352800 Hz the program is still using a relatively small number of taps/coefficients in the upsampling algorithm?

　

Whatever I so far have not been able to reproduce with the extraordinary sound quality that I briefly heard when @Sime V2 kindly brought his M-Scaler to my Qutest so I will have to try to deconstruct the sox source program more as @Ittaku has done

　

[Ittaku]

59 minutes ago, legend said:

Because I have other things to spend $7.5k on at the moment  (but fell in love with it when @Sime V2 brought it to my system) I have spent the last couple of weeks trying to investigate whether it is possible, and how well, to emulate it off-line. To start with the conclusion - I have not found it possible so far, though this may at least partly reflect limitations in my computing skills (unlike @Ittaku)!

　

I used the shareware 'sox' program that has the same sinc (sin/x) formulation to upscaling as does the M-Scaler. And because I don't have experience with C++ programming language (only Fortran from a long while ago) I used the Windows version of 'sox' that can be downloaded from https://sourceforge.net/projects/sox/files/sox/14.4.2/.

　

The sox.exe file runs in MS Windows command-line window. The 'rate' feature in sox contains its upsampling option with some sub-options. The most general command line I used is

sox -v 0.9 MusicFile.wav MusicFile-out.flac rate -v -L -s -a -b 99.7 352800

where -v 0.9 reduces the volume by 0.9 (approx 2 dB) to prevent clipping

MusicFile.wav is a ripped Redbook file at 44100 and 16 bits and must be in the same folder as sox.exe

MusicFile-out.flac is the upsampled file (created in the same folder as sox.exe)

The '-v' after rate specfies 'very high quality' upsampling (the highest choice allowed)

-L specifies linear phase (it can also be set M for minimum phase and I for intermediate phase)

-s specifies steep filter rolloff (and can be left out if not required)

-a allows aliasing at the cutoof frequency (and can be left out if not required)

-b specifies bandwidth

99.7 is the maximum badwidth allowed

352800 corresponds to 8x upsampling (the program fails with x16 upsampling).

　

An upsampling took about 30 secs for a 3 min MusicFile on my medium quality computer - with a AMD A6 5-core 2.60 GHz processor with 8Gb of RAM. The music was a mixture of classical, jazz and rock.

　

With all these independent variables it is difficult to try all permutations and combinations of them. However with the combinations I tried I did not like the sound quality of -s and -a so did not investigate them further.

　

In general I found the changes produced by my upsampling over the original Redbook file were obvious but fairly small using my Qutest DAC - and certainly much smaller than I remember given by the M-Scaler when it was upsampling x16 and using the dual SPDIF inputs to the Qutest (though also much less obvious at lower sampling rates).

　

I wonder if one 'problem' is that theQtest DAC upsamples all files to x16 so at least to some extent the Qutest overrides the effects of previous upsampling if this is lower than x16? With the M-Scaler I seem to remember its effects were also fairly small when its output was less than x16 and that dramatic (magic!) improvement in SQ seemed to mainly occur at x16 upsampling and so all the upsampling only occurs in the M-Scaler with its 1 million taps?

　

Certainly when I tried my upsampled sox files on my Project S2 DAC that I think does not itself upsample the effects of the sox upsampling seemed more pronounced (though the overall sound quality was not as good a the Qutest, not surprising given their price difference).

　

The other 'problem' may be that I am just using the 'very high quality' upsampling option in sox and even with extending the bandwith from its default value of 95% to 99.7% and the rate to 352800 Hz the program is still using a relatively small number of taps/coefficients in the upsampling algorithm?

　

Whatever I so far have not been able to reproduce with the extraordinary sound quality that I briefly heard when @Sime V2 kindly brought his M-Scaler to my Qutest so I will have to try to deconstruct the sox source program more as @Ittaku has done

　

 

Unfortunately there are quite a few hidden commands not documented in the manual. You can override the vhq quality with even higher quality. VHQ corresponds to 28 bit accuracy. If you use -d 32 (instead of -v) it will use 32 bit accuracy. The steep filter is the beginning of what I'm doing; it only corresponds to 99% bandwidth whilst I'm basically creating an ultra steep filter of 99.999% bandwidth. The regular steep filter only corresponds with a few hundred taps. I agree aliasing is a bad idea (-a) it seems to audibly adversely affect the sound. This is interesting because the topic came up many pages ago about whether allowing aliasing is audible or not, and basically you and I have now done that experiment and found that it is detrimentally audible. To get more out of sox (on windows) you'll have to compile it yourself with the patch I showed you. Compiling stuff on windows I find irksome whilst it is trivial on linux. Might be easier to just install a virtual machine or partition with a basic linux distribution if you're serious about trying this stuff out.

[legend]

6 hours ago, Ittaku said:

 

Unfortunately there are quite a few hidden commands not documented in the manual. You can override the vhq quality with even higher quality. VHQ corresponds to 28 bit accuracy. If you use -d 32 (instead of -v) it will use 32 bit accuracy. The steep filter is the beginning of what I'm doing; it only corresponds to 99% bandwidth whilst I'm basically creating an ultra steep filter of 99.999% bandwidth. The regular steep filter only corresponds with a few hundred taps. I agree aliasing is a bad idea (-a) it seems to audibly adversely affect the sound. This is interesting because the topic came up many pages ago about whether allowing aliasing is audible or not, and basically you and I have now done that experiment and found that it is detrimentally audible. To get more out of sox (on windows) you'll have to compile it yourself with the patch I showed you. Compiling stuff on windows I find irksome whilst it is trivial on linux. Might be easier to just install a virtual machine or partition with a basic linux distribution if you're serious about trying this stuff out.

Thanks for the advice!  A quick question so I am clearer of how to proceed.  Is the number of taps/coefficients an independent variable (that can be set externally) or a dependent variable (determined internally by the sox program on the basis of other independent/set variables such as quality, steepness, bandwidth etc)?  I get the feeling from your comments and from your patch that it is the latter ie not set externally but determined internally by the program?

[Ittaku]

3 minutes ago, legend said:

Thanks for the advice!  A quick question so I am clearer of how to proceed.  Is the number of taps/coefficients an independent variable (that can be set externally) or a dependent variable (determined internally by the sox program on the basis of other independent/set variables such as quality, steepness, bandwidth etc)?  I get the feeling from your comments and from your patch that it is the latter ie not set externally but determined internally by the program?

Dependent variable. Chord's magic 1 million taps (slightly over in fact) was - I'm assuming - worked out backwards for what was required to recreate an equal height 16 bit impulse after filtering, as I get a number close to theirs when I aim for that too.

[legend]

2 hours ago, Ittaku said:

Dependent variable. Chord's magic 1 million taps (slightly over in fact) was - I'm assuming - worked out backwards for what was required to recreate an equal height 16 bit impulse after filtering, as I get a number close to theirs when I aim for that too.

Thanks again!  A last supplementary question if possible please?   What output from the program tells one how many taps/coefficients the sox program has used?

[Ittaku]

1 hour ago, legend said:

Thanks again!  A last supplementary question if possible please?   What output from the program tells one how many taps/coefficients the sox program has used?

Add -V4 to increase verbosity enough and you get something like this:
 

Quote

 

/usr/bin/sox DBUG effects_i_dsp: make_lpf(n=629471849 Fc=0.5 β=17.4382 ρ=0.5 dc-norm=0 scale=1)
/usr/bin/sox DBUG rate: fir_len=629471849 dft_length=1073741824 Fp=0.9999999294482855 Fs=1.000000 Fn=2.000000 att=166.021 2/1

 

That's 629 million taps.

[legend]

11 hours ago, Ittaku said:

Add -V4 to increase verbosity enough and you get something like this:

Thanks. It shows I have been using around 10k taps - well short of the 1M of the M-Scaler.  Will have to try harder - be more serious!  So far have not managed to get "-d 32 instead of -v" to work.

Edited February 23, 2019 by legend

[Ittaku]

2 hours ago, legend said:

Thanks. It shows I have been using around 10k taps - well short of the 1M of the M-Scaler.  Will have to try harder - be more serious!  So far have not managed to get "-d 32 instead of -v" to work.

Without hacking the software itself, you can also make the filter steeper and have more taps by increasing the rejection depth. It allows up to 200, but that tends to overflow calculations so usually only 198 works, so try adding "-R 198".