Is Vista really capable of bit-perfect output?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Disabled Account
Joined 2006
Telstar said:
And I recommend you to stay away from USB.
Why the fear-mongering? Both the isochronous asynchronous and the bulk transfer modes allow the DAC clock to be master and are completely immune to interface jitter. Examples of each modes used in audio exist--EMU 0404 for the bulk transfer and Wavelength Audio's newer DACs for the latter. While the EMU is not a high-end solution and wasn't intended as such, there's not much wrong with Wavelength's DACs.
 
AFAIC, paying 70 Euros for a piece of software that can out-perform my 7000 Euro CD transport is pretty good value for money!!!

In any event, you can download the demo version for free and then decide for yourself whether or not you want to pay for the activation code.

Please bear in mind that when I started this post, I believed that XXHighEnd was equivalent to Foobar with ASIO. I now think differently, having used the latest 0.9u-1 version of XXHighEnd as a demo for a while.

Right now, I consider my 70 Euro investment probably the best I've ever made in all the years of having this hobby.

Mani.
 
I asked XXHE a question - "Why should XXHighEnd sound any better than Foobar with ASIO?"

In order to answer this, XXHE had to point out that, among other things:
- XXHighEnd is the only player available to make use of the 'Exclusive Mode' functionality in Vista
- XXHighEnd allows you to change the processor core appointment
- etc

How else could he have answered my question?

I'm totally happy with XXHE's response and appreciate his contribution.

Mani.
 
Disabled Account
Joined 2006
I read that post twice and I can discern not an ounce of an explanation. Here's what it looks like: he was challenged as to why his player should sound better than a player using ASIO, and then gave no satisfactory answer, and this indeed makes sense, because certainly his player cannot be better than a bit perfect output such as a proper ASIO implementation provides. As for processor core assignments--again, it doesn't matter. Now, if his player is doing some DSP on the data to add 'euphonic' colorations, for some people indeed that may sound better, but is clearly not what most people would refer to as "better".
 
XXHE said:
I use a slope starting at 5K that ends 16dB higher at 20K. The "solution" to this you will find in the 0.9u upcoming version, and all is done in the "bit perfect domain".

Peter [/B]

Abzug, remember, I was of the same opinion as you. How could bit perfect players sound different from each other?

I listened to XXHighEnd 0.9t and couldn't hear a difference, compared to Foobar with ASIO.

I listened to 0.9u and heard the difference straight away... and so did my wife!

I'm an experimenter by nature (PhD in experimental semiconductor physics) - I'd be interested in hearing your thoughts once you too have experimented and listened to XXHighEnd.

Mani.
 
Disabled Account
Joined 2006
manisandher said:
I listened to 0.9u and heard the difference straight away... and so did my wife!
1) Was it a blind test?
2) Are you sure the player is not modifying the data--are you certain bits in are the same as bits out?
If you answer either of these in the negative, nothing else is of any relevance.
Mentioning your degree is the least relevant of all things; all it accomplishes is making one wonder how a PhD doesn't know what argumentum ad verecundiam means.
 
Disabled Account
Joined 2006
Pseudorandom number generator running on the DSP, and a sequence generated from the same seed in a wav file. The intention was to check USB Audio error rates, but I will test this player when I get the next PCB set from the PCB house.

An HDCD codec has some robustness to limited changes to the data, specifically depending on where the changes are. I have no doubt one can construct software that will detect HDCD encoding and apply DSP effects while still outputting a valid HDCD stream.

You mention the sound card is slaved to the DAC clock. In this case, interface jitter cannot be an issue, and assuming the card is not performing any SRC and the data is also bit perfect, there is NO other possible way the player can affect the sound.

You should try a check for bit perfect output by recording the stream received by the DAC's S/PDIF input to an S/PDIF in on your PC, and doing a bitwise comparison.
 
Vista Exclusive Mode cannot be tested by the "usual" means like a DTS stream passing through unharmed. The sole fact that an encoded file is passing the Audio Engine of Vista just *makes* that bit perfect (an explicit action of the OS). This says nothing about PCM.

Indeed the only way to test for bit perfectness is capturing back the stream, and compare. For Vista it's worse again, because you'd need to capture the stream on *another* PC. With capturing too, Vista switches into a mode which would not be representative (and that mode is ... Shared Mode :dead: ).
As far as I can tell this can only happen with an external soundcard (in fact two PC's connecting to that).
When I tested it back then it broke my brains on how to set it up. It can be done though as I did it to at least prove to myself it all worked (bit perfectly) as intended.

Might you still be in doubt : there is NO way I will ever apply DSP of any sort. It's already worse enough that there's a digital volume in there now, but that's for a good (SQ) cause by itself.

Might you come to the test : set your "DAC is" at 44.1/16, and keep the volume at -0dB.

HTH,
Peter :)
 
manisandher said:

I'd like to do the bitwise comparison that you suggest. What should I use to compare the two wav files?

Hi Mani, allow me ...

This is not as easy as it may seem, and it needs some experience at this in order not to get crazy.

Let's say you can use something like WaveLab in order to read in both versions (source and captured copy), and compare them.
"Compare" to the sense of bit perfectness is not in order yet, because first you need to find a common denominator start point of both files. Without experience this can take you ages, especially if you are comparing files which are not equal anyway (like the captured copy is not bit perfect).

Once the common denominator start point is found, you'd have to cutoff the left part(s) so both will have the exact same start point.
Wavelab can now compare the files, and will ignore the end parts not being equal (it will stop comparing at the shortest file).

Sidenote : you will not be able to record the file with same startpoint as the original, because or you press "record" too soon or too late, or there's always a latency at auto-triggering recording.

Do not forget to use two PC's for it, as I explained in the other post (which btw was posted an hour earlier than your post, but came through later).

Peter
 
Disabled Account
Joined 2006
manisandher said:
I'd like to do the bitwise comparison that you suggest. What should I use to compare the two wav files?
I would insert a silence then a demarcation of some sort into the file, for purposes of synchronization. You can do that with a hex editor, though I'd just code a tiny C++ program. Then for comparison I'd just do byte-wise comparison. If the results differ, I'd probably load both files into Matlab to try to figure out exactly what seems to be going on.


XXHE said:
The sole fact that an encoded file is passing the Audio Engine of Vista just *makes* that bit perfect (an explicit action of the OS). This says nothing about PCM.
I accept this point, BUT
one could take a DTS stream, write it into a wav file, and play it back as a PCM since the OS has no way of knowing what the data inside is. Indeed, this is a test I'm hoping someone here will try, as I don't have any DTS receiver.

Might you still be in doubt : there is NO way I will ever apply DSP of any sort.
Good to hear, but then you need to explain how two setups both bit perfect can sound the same, or argue that another player using ASIO or kernelstreaming is not bit perfect.

It's already worse enough that there's a digital volume in there now
If your source music is 16 bit but the DAC and link 24 bit, then digital volume control will not cause distortion over a range of attenuation close to 50 dB, unless someone really botched the implementation. Of course, some DACs use schemes such as adding shaped noise to lower bits to fake information there (this was in some Wadia patents from what I remember) so this may not be the optimal setup.
 
Spartacus said:
Hello Peter, are you able to explain how one bit perfect player can sound different to another?

I can fairly say "no" because by now there's too much to it.

Please read this (so far) short thread if you want : http://www.phasure.com/index.php?topic=411.0

This is just a "live" representative of what's going on on a daily basis for a year or so, and *this case* (!) testifies that sound is influenced by means I know by itself, but which are out of my control really. BUt see more below too.

Allow me to summarize in very brief (and don't attack please because there's much more to it) :

First of all try to believe the truth in software really making a difference to sound quality. If you don't believe in it you'll never try, and btw you will call everybody a fool who (instantly) hear the differences. There's no placebo's going on, and rteal A-B(X)ing is not really necessary, because over people, everyone always hears the same as the others after an upgrade.

It comes very handy that people exist who suffer from, say, being over-exposed to jitter sensing, or at least that's what those people think themselves what they hear when things are wrong with audio and sounds in general. One of those persons participated in working out the theories around how to influence jitter almost two years ago now, and XXHE for that matter started as some DIY "research" project. Also, I just had in mind to create a good software player, because all of the others didn't sound right, but worse, different. So it was my only means to be sure what would be in there, and that no DSP stuff was going on.

Another of such a person you'll find in the thread I referred to above.
What you can see in that thread is what I myself (and you for that matter) can hear/sense slightly and slowly, such a person creaps away immediately or is just happy. In fact this goes way beyond our imagination, and the only thing I can say is that I can confirm they are right, because I know what I do in the software and can expect what those people hear in the first place.

So software can influence jitter ... :cannotbe:

For what those persons hear, yes. I myself may say no. But 100% sure I (the software) influences the DAC. And each DAC, no matter brand or type, can be influenced the same, to the matter of people perceiving the same. No matter how USB asynchronously it is connected ...

The thread I referred to shows a case of things being influenced out of my control. However, this is only a sad side effect of software which is insufficiently in my control anyway. Oh, it is, but it just can't be kept under appropriate control for the things it has to do to these matters.
The software which just *is* under my control is the core audio engine I wrote (referred to as XXEngine3), and one of its means to influence "jitter" is its Q1 slider (better : the result of it).

Please take from me : *every* line of software code influences the sound. It just does and hundreds of people will testify for it (if you only believe my guarantee that what is output is always bit perfect ... which can just be measured :) ).

So, the, say, skill one has to have, is exploiting that "feature" in a controlled fashion, and XXEngine3 just does that. BUT, because really everything matters, the surrounding software just influences the same, or more "powerful" when there's too much of it. And the only control I have over that is eliminate it when possible.

Assuming you still (want to be) with me, what you see in the thread I referred to, is that a kind of overdose which was applied in the latest XXEngine3 version, is compensated by the explicit influence of other software, although *how* it influences is not under my control. I can let it run or just not, and in this case it must run (this is the difference between Attended (it runs) and Unattended playback (it runs not, and only the core audio engine is alive.

Things are as fragile as can be and in fact completely stupid to be so. But they are. And, as fragile as the influence applied is, the more the impact in the workout can exist. It can't be repeated enough : differences are one-second judgements (with some experience) within one player, coming in more versions though. All bit perfect.
Similar are the differences between the various players, and the least we can fairly state as true, is that when my one line of software influences sound, it's obviously explained why all players sound different.

Peter


PS: This could be for better and objective understanding : start laughing ... Buring audio CD while XX playing
 
I accept this point, BUT
one could take a DTS stream, write it into a wav file, and play it back as a PCM since the OS has no way of knowing what the data inside is. Indeed, this is a test I'm hoping someone here will try, as I don't have any DTS receiver.

I don't think this can be useful. When the stream is decoded (into PCM) there's no receiver applicable anymore, and nothing will show "green lights" for a properly encoded stream. This can just go into the amps for playback (I don't have a DTS receiver either, and decode DTS in software).
So, in the end nothing will prove bit perfectness. ;)

If your source music is 16 bit but the DAC and link 24 bit, then digital volume control will not cause distortion over a range of attenuation close to 50 dB, unless someone really botched the implementation.

I know, and I know it's not a problem. My point was : people knowing me and my ever expressing "no DSP !" must have kind of dropped from their chair when I introduced digital volume anyway which *is* a kind of DSPing.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.