Why third party players?

[wgscott]

Many are claiming they can "hear a difference" between the same software compiled with Apple's new default compiler vs. the previously-default gcc.

 

 

[wgscott]

Having been told, here, that I am a "flat-earther" for suggesting the heretical notion that two audio files with the same md5 checksum cannot possibly sound different, I am curious which side of the argument you are intending to diss.

 

[Jud]

wgscott writes:

 

Meanwhile, over in the Audirvana thread ...

 

Many are claiming they can "hear a difference" between the same software compiled with Apple's new default compiler vs. the previously-default gcc.

 

Which sounds a bit crazy to me too, at first.

 

But...

 

- If you read the thread there is an uncanny consistency between the reports of the difference in sound between the gcc-compiled version and the llvm-compiled version. And since I build from Damien's svn changes prior to his new release announcements, I had heard a change in the sound with the new version before Damien even announced the change in compiler.

 

- Would you think it was crazy if you read about some software on a Linux or FreeBSD forum that the binary from Compiler X performed better than the *different binary* from the same source code compiled with Compiler Y? You can read any number of these messages on such forums or developers' web sites. For that matter, why should Apple itself bother to switch compilers if there were no differences in the resulting binaries? (I suppose licensing could be one reason, but I'm also guessing you can find performance comparisons between software compiled with gcc and the same source code compiled with llvm on Apple's developer site or elsewhere on the web.)

 

So why should audio software be any different? Unless we want to be "flat-earthers" about it and think that different binaries built from identical source code should perform identically, irrespective of all actual performance tests to the contrary.

 

[Miska]

For that matter, why should Apple itself bother to switch compilers if there were no differences in the resulting binaries?

 

Different compilers, different versions of compilers as well as different compiler optimization options naturally produce different binaries. As long as computational results (easy to verify) are the same the only difference is in the time it takes to perform the computations.

 

Since for example gcc has tens or hundreds of different code generation options, there's almost infinite number of combinations to try for those who hear differences between compilers/options. And you can spice it up even more with profile-guided optimizations, then the resulting binary also depends on your particular CPU flavor and the profiling test case... Now, if you don't fix the "same data doesn't sound same always" -problem you have practically impossible task for figuring out the optimal compiler and option combination. Have fun...

 

 

[Jud]

Miska writes:

 

Since for example gcc has tens or hundreds of different code generation options, there's almost infinite number of combinations to try for those who hear differences between compilers/options. And you can spice it up even more with profile-guided optimizations, then the resulting binary also depends on your particular CPU flavor and the profiling test case.

 

Though I found the menu selections to do profiling in XCode 4, since I don't know how to code I can't do optimizations, profile-guided or otherwise.

 

Thus, fortunately, the danger to myself and others is minimized. ;-)

 

[wgscott]

It does not surprise me that different compilers might produce different sounds. I have found over-zealous optimization within one compiler can make the difference in numerical computations between accuracy and arithmetic run-time errors.

 

My point, rather, is that not only can different player software sound different, but the same software can sound different depending upon how it is compiled.

 

This why I think everyone should write their player software in fortran and compile with -O0.

 

[Miska]

I have found over-zealous optimization within one compiler can make the difference in numerical computations between accuracy and arithmetic run-time errors.

 

Sure, no magic here, this is also easy to verify from the computed output.

 

But then it's not "bit perfect" anymore! We were talking about "bit perfect" playback, weren't we?

 

 

[wgscott]

when was the last time you put a bit-perfection meter on your system. (I have absolutely no clue how bit-perfection is verified.)

 

My favorite gcc options:

 

-Waggravate-return

-Wcast-spell

-Wcaste-align

-Win

-Wmissing-protons

-Wredundant-repetitions

-antsy

-fbungee-jump

-fexpensive-operations

-fextra-strength

-fjesus-saves

-fkeep-programmers-inline

-fno-peeping-toms

-fruit-roll-ups

-fshort-enough

-mno-dialogue

-pedophile

-vomit-frame-pointer

 

credit

 

[Miska]

(I have absolutely no clue how bit-perfection is verified.)

 

Jus mod the app to dump data going to the audio interface to a file and compare it with the input data?

 

Note that my playback is really rarely "bit perfect" since I'm applying tons of processing to it...

 

My favorite gcc options

 

/me++

 

 

[jhwalker]

Each compiler will produce a different resulting binary, with different size and possibly different performance characteristics; however, if the *output* from the binary is different (i.e., the audio stream which is output from the program), either the compiler or the program is broken. The same source code will produce the same output, regardless of the compiler used.

 

FWIW, I tested three different builds of the current code base (using the GCC, LLVM, and LLVM-GCC compliers), and heard no differences whatsoever.

 

[James1776]

"Or you are lucky to have good enough system that the same data sounds the same - just like it should"

 

Or the system simply does not have the ability to detect small but audible differences...

 

[Miska]

Or the system simply does not have the ability to detect small but audible differences...

 

I already outlined possibilities to check it. It cannot be very intelligently selective. If purposely made small differences in data are audible, then it has the ability.

 

 

[barrows]

In response to your thread which Chris directed here: I think the answer is that no on really knows for sure. Certainly bit perfection is not the only factor. If any developers of playback software know what is going on, they are not really talking. What you will hear is speculation... It is clear though, that playback software does make a difference. I have been following some discussions regarding PS Audio's Bridge network streaming device (this requires PS to write their own playback software to work) and everytime they update the code, the sound changes somewhat, all of the options were bit perfect! I know Paul McGowan at PS admits they do not know why the sound changes.

So, there is more to computer audio than many (anyone?) appears to understand (the same can be said of high end audio in general) and it is wise to audition some different playback options.

 

[Jud]

Have a look upthread at some of the things Miska mentions (software/hardware interactions, and certain hardware being more subject to these).

 

One can also look at the strategies of some audiophile player developers, and some other suggested tweaks:

 

- Some player developers try to minimize other computer operations by several strategies, such as memory play, exclusive access or 'hog' mode, and integer mode. (The developer of Pure Music has posted here discounting the putative advantages of integer mode, saying floating point/integer conversion is not CPU-intensive, and Miska I believe generally doubts at least any suggested differences in CPU utilization as a source of diminished sound quality, though I don't know his opinion about such things as disk I/O.)

 

- There are various suggested tweaks to minimize other computer operations, such as (on Macs) turning off Spotlight.

 

- A suggested Mac tweak that I've seen more than once (and very surprisingly to me, seemed indeed to make a small but discernible difference) is to have OS X run with a pure 64-bit kernel. This eliminates some 32-bit services running in the kernel; I don't know if that is supposed to account for any audio effect listeners may or may not really hear. ;-)

 

- Some player and DAC developers say sample rate conversions produce distortion. Peter, developer of both a DAC and XXHighEnd for Windows, is one; Miska, developer of HQPlayer for Windows and Linux, most definitely is not. :-)

 

So in very broad summary, we have 3 general categories of more or less plausible explanations:

 

- Particular software players producing interactions with particular hardware that does not occur with other software-hardware pairings.

 

- Additional things running on the computer with some players that may produce electrical interactions in the hardware chain.

 

- Sample rate conversion.

 

[PeterSt]

(And my wife, as I like to point out, is no audiophile - she puts up with my "testing," but she's really just waiting for me to be done so she can get back to watching Oprah.)

 

Well, at least that will stop very soon.

 

:-)

 

[PeterSt]

What is the technical mechanism of this intended effect if the players are sending the same data to an async interface?

 

Far too small buffer size.

Over and out (no handwaving though :-).

 

[PeterSt]

From Miska :

 

What I'm trying to emphasize is that even though something partially manifests itself through playback software (and all other used software components) it may not be due to what the software is specifically and intentionally doing. You can play with a rays of light using lenses and mirrors, but it still doesn't change amount of light nor it's source. I'm chasing the source.

 

(emphasis is mine) Well, that's at least what I'm always saying.

Except for one piece of software of course, mine.

 

As I tried to counter attack that via an immune DAC (see earlier post(s)), I think I'm now in the stage of counter attack it via the software itself. So, XXHighEnd contains some controls to influence SQ within this one player, and I'm trying to not let them influence anymore. Not by eliminating them as functions, but by attacking stuff at another level.

 

For those following Phasure a little, it is quite easy to see that it already works to a certain extend. Just follow the individual threads as responses to a new version, and notice that suddenly it got quite quiet. No raving anymore about people finding new combinations of settings and perceiving better SQ again. It suddenly stopped *plus* I exactly predicted that.

 

Whether this means that XXHighEnd now delivers the ultimate SQ or something which is no good (but quite fixed) at all, is something else, but there are no complaints about SQ either (and you can bet people would shout if things would have turned out for the worse).

 

So isn't that interesting, thinking of "evolution" ?

I created the whole thing, and now I'm eliminating it by its own means (and sure not by some accidental finding).

 

Peter

 

 

 

 

[Jud]

Well, at least that will stop very soon.

 

OMG, you should have seen the tears! (From Oprah and my wife.)

 

[Jud]

So isn't that interesting, thinking of "evolution" ?

 

I already liked it, so I will have to try it again. And I'm going to make another attempt to get Miska's player to work, though I do no upsampling, since the DAC won't handle it (could downsample high rez, though, if I wanted to try that) - I am very curious to hear it, but was unfortunately unable to get sound from it last time I tried.

 

[PeterSt]

Many are claiming they can "hear a difference" between the same software compiled with Apple's new default compiler vs. the previously-default gcc.

 

... which is known for ... ? 6 years or so by now in Foobar circles ?

 

Really nothing new here !

 

Different compilers, different versions of compilers as well as different compiler optimization options naturally produce different binaries. As long as computational results (easy to verify) are the same the only difference is in the time it takes to perform the computations.

 

Miska, don't you think it's time to look some further than your own rooms there ? 6 years really is a LOT to miss, if you're in the field.

Don't re-invent wheels ...

 

Funnily enough, back at the time I started XXHighEnd (under the hood) together with the guy producing the best sounding "compiles".

And FYI : This worked with Profiling locally (I mention this, because I recall you mentioning it yourself somewhere, though in another context).

 

The effect is relatively small though, and can't contain any real directed influence (try combinations and hope for better sound).

 

At least this "prooves" how different players produce different sound (but those developers also pray in advance).

 

Let me add to it, that by now and at last times are changing a little, and I really can't say anymore that I'm the only one explicitly working on better sound. Too many parameters for it exist, and although maybe nobody understands them (e.g. memory playback), they sure *can* be applied explicitly.

 

I am sure that at some day all will be clear and in the open, but I don't think I will start the subject. I guess I have too much fun with the hunting from everybody (or so many). It may be a matter of my own priorities as well. I'll just start another subject, if the one secret is unveiled.

 

Maybe I must say "sorry for teasing instead of explaining" ...

 

Peter

 

[PeterSt]

I already liked it, so I will have to try it again. And I'm going to make another attempt to get Miska's player to work, though I do no upsampling, since the DAC won't handle it

 

Jud, it's a kind of too much typing to explain it all again in here, but I don't think many will agree with "upsampling" working out for the better. At least I don't think so.

 

In this area much more is going on, and it's all related to how the DAC destroys at first, which can me more or less counter attacked in being ahead of it all, so the DAC won't do much (of its destroying) anymore.

It sure can workout for the better, but there will be (again IMO) no general rule. It will be the combination of the "upsampling" software and the DAC, both acting with their own algorithms and physical workout.

 

But then this is why things start to be quite different when both software and DAC are made with this phenomenon in mind (see that large hardware vs. softare thread).

At least then (the DAC doing exactly nothing) the software can be judged 100% and the results will be predictable and consistent.

 

In either case, we should stop thinking about "upsampling" as such (that's why it's in between quotes), and instead think about the filtering process. It is this which creates the vast part of the sound ...

 

Ok, I guess this is offtopic here.

 

Peter

 

[Miska]

It sure can workout for the better, but there will be (again IMO) no general rule. It will be the combination of the "upsampling" software and the DAC, both acting with their own algorithms and physical workout.

 

I've been kind of tempted to publish a list of DAC chips and how they work in combination with the software. Generally, there's an improvement, but the amount varies depending on the DAC chip and whether there's some hardware ASRC in the middle or not. I've already put out some particular recommendations for some settings.

 

Analog side is kind of easier, because the benefit for it can be generalized more.

 

But then this is why things start to be quite different when both software and DAC are made with this phenomenon in mind (see that large hardware vs. softare thread). At least then (the DAC doing exactly nothing) the software can be judged 100% and the results will be predictable and consistent.

 

I have also these kind of solutions, but the DAC approach is still different from yours.

 

 

[One and a half]

is wayyypast my expertise and knowledge. Suffice to say, standard itunes is bit perfect on a Mac. That doesn't mean it sounds reference material, but the sound quality of the add ons like Amarra & PM do work, and work well, let your own ears be the judge. The weaknesses for standard itunes is low detail, ambience, soundstage and delivery, plus a few more.

 

On a scale 1-5 here's my perception of sound quality for itunes and 3rd party players.

 

itunes on Windows = 1

itunes on a mac = 2

itunes + PM = 4 to 4.5

itunes + Amarra = 4 to 4.5

Audirvana with INT= 4.3+

 

Anyways, PM and amarra are free trial, so give it a go. Audirvana is $0 and a lot less trouble free than the paid apps, still has some way to go for usability, but SQ is very good indeed.

 

Upsample is a hot topic around here, just duck as the daggers fly.

 

Happy listening!