Allow me ...

I don't think anybody will be against the possibility of playing a 96/24 file which plays as 96/16 for those having "DAC is" set to XX/16, or IOW for those who have a DAC that does allow for 96KHz but where the DAC supports 16 bits only.

This will cut the least significant 8 bits, of which I "state" that you won't hear the difference anyway, as long as you don't play very loud. Theoretically you will be able to hear it once you digitally attennuate LESS than 48dB (like 42, 36, ...).
Note that in this case there's actually no difference between attenuating digitally or analoguely, and it is just about putting the volume so loud that the data of the MISSING lower 8 bits becomes audible (as harmonic distortion). This will lead to the same audible distortion as cutting way the lower bits by means of (too much) digital attanuation as described elsewhere.
My reference to "digitally attennuate LESS than 48dB" is useful because with digital attennuation you can try out the level as set by analogue means above which you should not turn the analogue volume. So as long as you stay under the digitally checked -48dB level, you must be okay.

Is this a bit clear ?

Huraayy, my 48/16 USB DAC now can play 96/24 too !! All it needs is foolbar !

Dave, you're hoaxed ...


This is what Foobar does, no matter what I set the output bits to (0.9.4.4 here).
Also, resampling will take place, although I can't prove to which sample rate. On that matter, note that Foobar can work around the Volume Mixer of Vista, which is what I use here. So, that can't say anything today. What *does* say things, is that during playback (of that 94/24 file) I can "test" the sound device via Vista's "Test" (rightclick on the device), and the test sounds go right through the music. The other way around works too : first the test sounds, and right through that press Play in Foobar; then too both will sound.

At this moment I vote for the Stello (and what else) *not* being able to do 94/24. This is completely logic, as long as legacy USB can't deal with it AFAIK.
Terje, please grab a DAC of which you are sure it can do 48/16 max. Now take Foobar to testify that you shouldn't take Foobar to test this. Ok ?
You still can be right (and are certainly allowed to ) but the means to prove it must be, say, acceptable.

Peter

Hi Mani,

It has been quite a while since I looked at hese kind of tests, and I actualy wonder whether I ever did on Vista. This is kind of related to the Exclusive Mode capturing (hence recording) "facilities" which change something to the state of things ... of which I by now forgot the real merits. It is related though to the measuring of bit perfectness which therefore is quite a task in Vista Exclusive Mode. This is the reason why I needed two Firefaces to check for that in the beginnings (which I mentioned somewhere recently ... I even recall your name associated with that ?).

I must say though ... tonight I was listening more explicitly to Upsampling (which as well as Doubling I didn't for many months) with my wife and we were talking about the "buzz" slightly coming back, and for which XX is kind of "fameous" of not having it, like I (honestly ) talk about in the previous post here :


Now look at your graph at the low end ... (and see subwoofers (which I use) make something out of that ...)

Thank you very much Mani.
Peter


PS: You don't hear *me* say that this is the way to improve sound.. More life-like or not ...

Let me try to explain a bit, but please *also* try to understand somewhat It is important for your trials.

First of all, and as you will recall, even WMP itself allows for ripping to a header format which is not any official standard. That it *then* can play that back itself is nothing else but logic. It is still plain wrong. This is just an example, only slightly related to your topic here.

Then, that "a" player allows for playback of, say, 96/24 files, does not tell that it utilizes the 24 bits. Mind you, you wouldn't be able to discern if you don't know what to look for. When the lower 8 bits (LSB's) are cut during play back, you must play way loud to get that into the picture. And the remainder 16 MSB's ... same resolution.
If XX plays such a file, it plays the 24 bits guaranteed, except for tweaking the chain so that it all ends up in a 16 bit DAC, while in advance it wasn't rejecting because the soundcard (!) reports 96/32 as a possibility.

32 ? yes 32, because I expect all DACs to work with 4 bytes (2 words) at a time, and the least siginificant byte is skipped.

Besides the above, I can tweak things so that they work out okay, but are not. This happened with Doubling (and Upsampling) before 0.9u-1. Just mangle with two "parameters" and it totals out right. But the paramaters are still wrong. This "came out" at the necessity to address the soundcard/DAC more officially, and since the parameters now are right (which already happened at 0.9u-0) people couldn't play Double anymore. We now are in the area of Vista Exclusive Mode being buggy, and especially the acceptance of DAC's parameters. If you look at your "analysis" list, you see that *and* 24 bits *and* 32 bits are accepted by your soundcard, which I can guarantee is not true. But, Vista Exclusive Mode accepts it. Now for fun try to get the grasp of this :

Each properly organized 96/24 file will urge for the exact same parameters as your 24 bit analysis entry shows. Physically it would just be correct. BUT IT NEVER CAN PLAY LIKE THAT when the DAC accepts 32 bits only. And here is where it goes wrong in the first place : it needs tweaking. Let's say that the file needs an additional byte per 3 bytes. Without that it can't play because your DAC (or soundcard) can't handle it. I call this "tweaking" but in fact this is a very normal operation. BUT :

Where all really goes wrong, is that very officially the file tells Vista that it needs 96/24 hence "DAC needs 24", and this can never work out for the reasons I told in the above. Still, it is the file telling it ... this is how it's constructed. This, btw, is the reason that the Analysis function needs a file in the playback area. Without that, the whole process won't start, because deep down in kernel mode this file is read for its parameters (with the outcome that looks like one according like of the analysis report). Now, just for fun, and in between the lines again :

I did not start for nothing with mentioning the WMP rips. You know, those rips created by an MS product. Well, that exact same rips are rejected by the deep down kernel whatever again MS program I mentioned above. Isn't that big fun ?

We no slowly get the hunch of what kind of "tweaking" it needs to get things going. So, after things have been approved by a deep down program, stuff is sneakily changed. Same with the oh so normal 96/24 file which can only be accepted as a 96/32 file. As said, making a 32 file of it is a rather normal operation, but in this case the 96/32 also has to be told to the mechanism that will start the DAC running. So, this is another "tweak".

Because what the soundcard/DAC accepts is different from what the official routines for it come up with (this was changed from 0.9u-0 to 0.9u-1) there now is the potential of being able to play, whereas before it just was not. Typicle example : 88.2/24 playback, which is just always rejected by such a deep down routine, while actually the DAC and all can do it. So, this routine is now skipped ...

Very nice ! bit *NOW* it's more up to us. You actually. Because *now* you are able to play things which actually can't. Like hiss ...

Long story, but what it comes down to is what I said already (elsewhere I think), and that is that the Analysis function must actually play. If that works for a combination, we can be safe it works indeed. One thing (and that's why I didn't create it so far), it can't so without your own confirmation "it played allright". Thus, when playing commences, that Analysis program can't see whether it sounds allright or gives hiss only.

?
I think you're okay.
The long story is there to create some understanding in order for yourselves to tweak better. Or, being better able to tell me what you think is going on.
In the end we're helping eachother, because in the end all will just work. Mind you, while it officially can't. In the end I will have tweaked those "wrong" files as well, similar to the 44.1/16 WMP rips. But it takes a loooong time to find what's wrong in those files, which begins with not knowing what officially is written in there. It could even be coverart !

So, this time you most probably were so unlucky to again use a program that makes a format which is not official. Better try the FLACs (from Linn). They work ... (I must be careful with this, because I think I used a FLAC which I converted to WAV by means of Foobar (before XX could play FLACs)).

Anything else ?
 

Hi,

http://www.phasure.com/index.php?topic=367.msg2430#msg2430


What do you mean by "restrict" ? I don't restrict that ? ... or I don't understand what you mean ...
Both means of transporting data to a 24 bit DAC are supported, but so far I did not meet a DAC really accepting the 3-byte transport means. Still, it is just in there ("DAC needs 24 bits").

If you mean the Analysis function ... that just tells what your DAC supposedly accepts ... the 24 or the 32 transport means. I don't do that, your DAC does, *OR* what Vista Exclusive Mode makes of it ! So far, when it tells that the 24 bits transport means is "supported" it's not really true ...

So ... can you be more clear please ? but keep in mind your test 96/24 file; it's just no good (officially !).
Peter

The GDI+ error ? or what ??

Most probably, yes. Could be Energy Saving Options somewhere, but it highly depends on ... things ?
I think software-wise I should be able to do all, but these things may be difficult to find and implement. I have it in mind anyway, like more tweaking with the Services and all. You know ...

Btw, my drives spin up in approx. 10 seconds, and fall asleep in 10-20 minutes or so.
Note that Vista Energy Settings have a high degree of instableness. I think most of that will be solved in SP1.

Thanks Russ.


"Resets back" ?

I'm not sure what technique Russ uses to determine all is right, but I think I get the grasp of it.
His highly intelligent processor presumeably shows which bits are actually USED. So, with a 44./16 file playing (which Russ doesn't mention, but I hope he is doing that) and the volume at -0dB, indeed only 16 bits are used. There aren't anymore in the data AT THAT MOMENT.
When 6dB is attenuated, what happens is that the 16 available bits are are shifted one bit, and it goes into the available headroom of the more than 16 bit capable DAC. So, now 17 bits are being used. Note that actually this is not true, because the Most Significant Bit is out of use now. So it's still 16 bits.

Hey smart*ss downunder ! did you find this out yourself, did you just know it, or did it take a couple of days reading the Sony manual ?!?
I must say, I'm really surprised ... Hats off !


And Russ, my "24 bit" question was about my suggestion that you could not use the "DAC needs 24 bits" setting (so, 32 only). Am I right ? or can the Jui@ take both 24 and 32 bits ?

Thank you !
Peter

One other thing maybe ...

If you find yourself pressing the Search button, I think you do something wrong already. I mean, I *never* do it, because all works with "Active Search" (just kind of slowly typing in that area). The only thing is, sometimes it doesn't work properly, and then I back out a few characters, until I see "movement" in the Library Area again. And then type forwards again ...

You must be doing something wrong or possibly don't understand how it works ?

I have over 6000 albums in one "group" like Rock. When I access that for the first time, it indeed takes maybe 30 seconds to collect them. This is when nothing is in cache, so say the first time I do it after a reboot.
Now, no matter what, when I go in there a next time (XX shut down and restarted and all) it takes less than one second. Even after a reboot.

When I change to one of the others with, say, 400 albums in there, that again takes less than one second because it's so "few".
When I then pop back to the 6000, it may take 5 secons because all is in the PC's cache memory.

This is all from an IDE (PATA) drive (where I keep the Galeries), so it can be way faster when stored and used from a SATAII drive.

I really don't need more speed ...

What I can do though, is provide a checkbox that allows you not to count the number of albums in a folder. That makes it, say, 10 times faster ... (and you don't have the numbers) ...

But Russ ... You are not going to tell me that you can get the 24 bit possibilities actually to work ? or ??

Assumed not, this now leads me to the thought that this analysis thingy must dive deeper. Kind of right to the end and playing. If *that* works, then it would be actually true. One exception : crackles. But I can't believe it will come that far.

I will change the analysis accordingly.

Today I coincidentally ran into a post mentioning this error as caused by the (W?)LAN driver.

Also, if you have Bluetooth on board (and you don't use it), try to uninstall the drivers for it.

Btw, when you briefly quit (Off) the player and restart it, it's okay again, I found.

Thank you Gerard. I notice similar things lately. I will look into it !