Andrey, can you tell at which settings you do this comparison ?
And can you describe for a simple soul like me i.e. in for me audible terms what you hear (as differences) ?

I assume you compare Unattended only ?

Lastly, wouldn't it be better for you to play with the Mem box checked ? (but first look whether it makes a difference at all, which you can see by the memory useage).

Peter

Are you crazy ? to me it is ...

But I hope it's gapless !

HUH ?
Can you please tell :

a. This is about subsequent tracks from the same album ?
b. Is this with Mem checked or not ?
c. Double etc. ?
d. With Unattended this doesn't happen ?

Thank you for mentioning this. I wasn't aware of it, although it is something which could be expected. Now, however, I can start looking for the differences explicitly.


Accepted and appreciated !


I know it is important, but I didn't know how to express it better. It would be an XX invoked IO;
Maybe you recall that I anounced that my own system started to act weird because of the playback now being more "persistent" (as how I explain it). This click too - when I am right that this comes along with an I/O (just one small blink) - makes me think that indeed time slicing isn't working properly anymore (or hmm ... maybe I should lower the prio now, which is at real time). The attended playback not being gapless is another indication of that. Note that in the Attended case the files are fed by XXHighEnd. I've been looking at 10ths of tracks, and it now just starts doing that when the playback from XXEngine3 is finished. And they're both unrelated !!

It's also a good reason why for the life of me I can't find anything wrong in the code.

But I think I can try some new things, with your last post in my hand. Thanks.

Btw, you needn't try 0.9u-10 for these things.

Edward,

After rather extensive paying attention tonight, I noticed that Attended playback actually doesn't play gapless anymore.
Also, the one time I experienced a small click (which was at Unattended), this came a long with a disk I/O (amongst other disk I/O's).
This is a tough one ...

Well, I hope the only thing which is broken here is the electronic filling out of tax forms (some other x million dutch will be doing today).
Guys, try doing it separate for you and your partner. Won't work anymore.

Hehe Russ, I know it's getting late out there, but I don't think it works like that. Look :

44.1 x 16 = 705.1 right ? but it should be 1411 ...

Besides, in your math of 32 x 48 = 1536, the fact that it's 24 bits isn't incorporated. And no, it is not 32 bits because we're talking about the INPUT, and then your math would be 24 x 48 = 1152. But in both cases you it seems to be allowed to simply it by means of multiplying by 2 (the actual math goes more complex).

Now, when it is most probable that you indeed cut the 24 bits to 16 during the process (of ripping - reauthoring), I think I can fairly say that before all worked because with the DAC set to more than 16 bits, it worked out to code processing 16 bits only anyway. It are these things which have changed (lately). Now :

What I explicitly applied for 44.1/16 best SQ, I have now done just the same for 48/16 and all of the other /16 sample rates (up to 192000). So, with the below XXEngine3 it all should work again for the DAC Is set to more than 16 bits. Please note that the playback code is exactly the same, and indeed you don't need to switch the DAC Is for that.

Obviously when this now all works, you have re-ripped your DTS 24 bits files, and now *they* don't work .
But I think they do ...

Ok ...

I've downloaded an assumed 48/24 DTS, and the bit rate it shows is ... 1536.

Now, what do I miss ?
I think we all agree about a normal 44.1/16 having a bit rate of 1411. So, (1411 / 44100) * 48000 = 1536, right ? So where are the additional bits ?

Two wave editors show the same ... 48/16.

Please note this is not only about the bitrate, but also about the "words" forming a sample. This just says two bytes (16 bits) ...
So, if this is supposed to be 24 bits really, there's no way I can discern (I think).

What remains, is how did this play before then ?

??

Russ, I think something else is going on.

First, in the program I can't see what is wrong.
Second, the bit rate for an 48/24 should be 2304 (padded to 32 bits !!). It just is doing that ...

How this is related to DTS, including that before it worked, I don't know. But IMO when you set the DAC to 16 bits and it plays, you'd be playing with 16 bits. The other 8 are just cut.
Possibly before that just happened the same, but with DAC is set to 192/24 (etc.). I can't tell (without rather excessive back tracing).

In either case (DAC is 16 or DAC is 24) a normal 48/24 file (no DTS) just plays. And on this matter I can't see the difference with encapsulated DTS ...

But can the 1536 be right with 24 bits ? I mean, it shows that too on 16 bit files. How can that be ?

Yeah, but ... Apart from that I will make it work as should (being : it not being necessary to set the DAC to 44.1/16), does your receiver show that it's capturing 24 bits ? I hardly can imagine that, but I also can't imagine me making 16 bits of a 24 bit file and your DTS decoding still works ...

This one should work better. Indeed the Mem box doesn't help (as far as I can see).
I couldn't check 24 bit files.

Sorry, found some 48/16 as well.

I think I found a way to check theoretically. So if you have those links please ...
The only one I have is 44.1/16 DTS. Nothing else ...

Btw, in any case, and from theory, it is better to try everything with the Mem checkbox checked. Did you try that ?