Page 383 of 804

Re: MQN

Posted: Sat May 31, 2014 8:31 pm
by tony
Haven't got near the new ones but 3.14avx or 3.27avx are my favourites.

The biaural sounds interesting even though I haven't listened to the headphone amp in a long time wouldn't mind hearing what that sounds like.

Re: MQN

Posted: Sat May 31, 2014 8:33 pm
by cvrle59
With my limited experience with different formats, I have no problem to understand this...
http://people.xiph.org/~xiphmont/demo/neil-young.html

Tip: Styles can be applied quickly to selected text.

Posted: Sat May 31, 2014 9:00 pm
by Aleg
cvrle59 wrote:With my limited experience with different formats, I have no problem to understand this...
http://people.xiph.org/~xiphmont/demo/neil-young.html
Do a search on the Naim forum for a few years back on this article.
This one showed a number of flaws in the article: http://forums.naimaudio.com/topic/are-2 ... ess?page=1

This article has been shown to be flawed several times, but it keeps turning up.
Just ignore it.

Re: Tip: Styles can be applied quickly to selected text.

Posted: Sat May 31, 2014 10:37 pm
by cvrle59
Aleg wrote:
cvrle59 wrote:With my limited experience with different formats, I have no problem to understand this...
http://people.xiph.org/~xiphmont/demo/neil-young.html
Do a search on the Naim forum for a few years back on this article.
This one showed a number of flaws in the article: http://forums.naimaudio.com/topic/are-2 ... ess?page=1

This article has been shown to be flawed several times, but it keeps turning up.
Just ignore it.
I just noticed that I made a spelling mistake, I can't correct it now, but I was going to say "I have problem to understand this...".
Thanks Aleg!

Re: MQN

Posted: Sat May 31, 2014 11:06 pm
by jkeny
The main problem with this article & similar approaches are statements like this:
So the math is ideal, but what of real world complications? The most notorious is the band-limiting requirement. Signals with content over the Nyquist frequency must be lowpassed before sampling to avoid aliasing distortion; this analog lowpass is the infamous antialiasing filter. Antialiasing can't be ideal in practice, but modern techniques bring it very close. ...and with that we come to oversampling.
This seems to present a fair & balanced statement but actually skips the real world complications somewhat frivolously.

The real world complications seems to be that with almost all current DACs (i.e sigma delta DACs) inputs are oversampled - so audio of 44.1KHz is oversampled (8 times) to 352KHz & reconstruction of the waveform at the output (usually called the reconstruction filter). Both of these processes involve generating new samples between the "actual" digital samples. Generating new samples is guesswork - mathematically sophisticated guesswork but still guesswork. Very accurate guesswork requires very powerful processing and a very large number of samples - both of which are not currently available in existing DACs. I guess the issue is how accurate does this waveform have to be for it to be audibly transparent & this is where all the arguments begin :)

So avoiding some of these limitations of the DACs by more accurately pre-processing the data before the DAC seems to make sense? In other words 192KHz samplerates (4 times 44.1KHz) relieves the on-DAC processing somewhat - 384KHz (8 times) avoids the input overampling filter altogether - (we are still left with the reconstruction filter on the output but the "actual" samples are closer together & so the "guessed" samples can be more accurate.

All the arguments & counter arguments of the audibility of frequencies >20KHz is a red herring, in my opinion.

Edit: To get an idea of the variability of sample rate converters (SRCs) - see here http://src.infinitewave.ca/
These are software based & yet there is substantial differences between them - even though the processing power & memory available is far greater than that available on DACs

Re: MQN

Posted: Sun Jun 01, 2014 3:12 am
by jesuscheung
am shock to see people still believe in oversampling!

let's say oversampling once sounds better
44->88

oversampling again, will be even better

why don't you oversampling 2000 times

i can bet right now, it is gonna get much worse.

this "tweak" is not accumulative.

there are things in hifi when you do same thing over 2000 times, it shall improve 2000 times. oversampling isn't.

Re: MQN

Posted: Sun Jun 01, 2014 3:16 am
by jesuscheung
by the way, is oversampling even backward compatiable?

in the other way, after you oversample from 44 -> 88
and downsample it back from 88 -> 44 i doubt you can get back the original music unless you know the original algorithm

again, this shows you are listen to algorithm. not exactly the original music. (but then, who cares, the oversampled music is better. original is now worse off... why not oversample, downsample, oversample.... keep doing it. you have best music)

Re: MQN

Posted: Sun Jun 01, 2014 7:02 am
by Karl
Read number 9:

http://www.lessloss.com/faq.html

and the whole story

http://www.lessloss.com/dac-2004-mkii-p-194.html

Nowadays excellent oversampling filters are programmed in FPGAs.

A test for software SRCs:

Up- and downsample one file 5-10 times and compare.

Re: Tip: Styles can be applied quickly to selected text.

Posted: Sun Jun 01, 2014 11:00 am
by sbgk
Aleg wrote:
sbgk wrote:he was right though, 3.81 onwards are a bit easier to listen to
No, he was not right, he just has a different opinion because of his personal preferences.

Gordon you work in IT, and know about architecture of systems.

What would you say is the function of a software player in the complete playback chain from digital file to speakers?
What is its purpose in reproducing music?

I'm very much interested in your answer on this!

Cheers

Aleg
the software player is trying to copy data from source to device while producing the lowest electrical noise possible. To do that the aim is to have the data in L1 cache just as the cpu needs it otherwise costly stalls occur which can cause 10s of cycles to occur as the data is fetched from ram. There are various prefetching mechanisms, hardware dcu prefetch seems to produce most detail, but is also harsh to listen to, other mechanisms produce a softer sound. Hardware prefetch does produce more electrical noise and I believe this causes the harshness, I also read the hw prefetch only kicks in for the second cache line, when I prefetch the first cacheline the sound is softer. So I wouldn't be surprised if the perfect player produces a detailed soft sound.

uploaded 3.83 which has the first cacheline fetch as well as hw prefetch.

Re: Tip: Styles can be applied quickly to selected text.

Posted: Sun Jun 01, 2014 11:25 am
by Aleg
sbgk wrote:
Aleg wrote:
sbgk wrote:he was right though, 3.81 onwards are a bit easier to listen to
No, he was not right, he just has a different opinion because of his personal preferences.

Gordon you work in IT, and know about architecture of systems.

What would you say is the function of a software player in the complete playback chain from digital file to speakers?
What is its purpose in reproducing music?

I'm very much interested in your answer on this!

Cheers

Aleg
the software player is trying to copy data from source to device while producing the lowest electrical noise possible. To do that the aim is to have the data in L1 cache just as the cpu needs it otherwise costly stalls occur which can cause 10s of cycles to occur as the data is fetched from ram. There are various prefetching mechanisms, hardware dcu prefetch seems to produce most detail, but is also harsh to listen to, other mechanisms produce a softer sound. Hardware prefetch does produce more electrical noise and I believe this causes the harshness, I also read the hw prefetch only kicks in for the second cache line, when I prefetch the first cacheline the sound is softer. So I wouldn't be surprised if the perfect player produces a detailed soft sound.

uploaded 3.83 which has the first cacheline fetch as well as hw prefetch.

Gordon

What processor do you use?
I use a Core i7 and I just read on Intel's page about prefetching there might be different prefetching implementations for different processors:
Hardware prefetching is implemented by your processor and will be different depending on which processor you use. Most recent Intel processors have several different hardware prefetchers. The Core™ i7 processor and Xeon® 5500 series processors, for example, have some prefetchers that bring data into the L1 cache and some that bring data into the L2. There are also different algorithms – some monitor data access patterns for a particular cache and then try to predict what addresses will be needed in the future. Others use simpler algorithms, such as fetching 2 adjacent cache lines. The pattern matching and detection algorithms used by the set of hardware prefetchers on the Core i7 and Xeon 5500 is improved from our last generation, and we continue to optimize these algorithms with each new processor architecture.
I was wondering if there might be differences in sound quality when using hardware prefetching on different CPU's?

Cheers

Aleg