Now I think of it ... there is another difference :

You would be using Vista SP1 (which is W2008), while I use SP0. And, since all (audio stuff) is so buggy in there, *and* Peter from Foobar says that really SP1 is needed it might just simply come to this :

I couldn't get the 24 bits going because of a bug in Vista, and now I just could. And, because I couldn't get it going, the way it tries it in the current version could be just wrong (remember, I couldn't test it because it just never worked -> chicken-egg thing).


Maybe you already told it, but what happens if *you* try the 32bits in Foobar ?

Ok, here's some thinkering ...

I looked at Foobar again, and I found a difference. Foobar will not output in 32 bits. That is, I receive an error from that setting. Now, XXHighEnd ONLY outputs in 32 bits (hence not in 24). Why ? well, because

a. my Fireface soundcard (/DAC) won't operate when fed with 24 bits
b. I didn't hear from even a single person that he couldn't use 32 bits (per the way I do it), or the other way around, that 24 bits was *needed*.

Ad a.
Somehow it must be my lacking knowledge that I can't (or couldn't at the time) get this going. I conclude this by
1. Foobar throws an error for 32 bits hence the 24 bit setting really must be different;
2. Foobar plays those 24 bits through the same soundcard/DAC which I (in XX) can't get going.

Ad b.
You might be the first.
Also, how could one ever tell without the comparison means, which now exists (Foobar). Thus :
More people might be suffering from this, and think it is their driver.

Despite the above, and assuming it is true that your sound device really needs 24 bits (and can't use 32), it still will be rather "impossible" for me to create something that works, because I can't test it as long as it just doesn't work (kind of your situation). Also, Foobar not allowing the 32 bits looks fishy to me the least. Why ? well, because the error thrown doesn't come from Foobar but from WASAPI, and it is just the same as the one you receive when you receive the Endpoint Create Failed message. Now here we have a problem, because this implies that both (XXHighEnd / Foobar) work mutual exclusive the other way around, and that can't be ... Added to this, is that I of course know what I'm doing, so without doubt I am outputting 32 bits. And this implies that Foobar is wrong, but I can't tell in what.

The latter isn't much important, weren't it that we both try to use Foobar to work out why XX doesn't play in the same situation. So, it *is* important.
Btw, sadly, I can check the bits used only up to 24, so I can't check whether Foobar by accident has things twisted (plays at 32 when set at 24 and the other way around (which then indeed doesn't work, like with me)).

Important : Might you check things yourself sometime again, always quit Foobar after a change in the bit depth area, and restart it. So, restart playback isn't enough, and you really can't see the difference (I can with some software I have).


What I will do next, is trying to find a way to let my DAC work at 24 bits, or prove otherwise that each soundcard / DAC needs 32 once more than 16 are in order.

Ok, thank you very much. One small (but important) thing though :


Do you mean the one I uploaded yesterday, or the one received with the normal download ?

Oh help, I am getting lost on this one.



These both do not combine for me. Double is exactly the same as Double/Upsample regarding the "setting" of the soundcard/DAC. So, if you are correct about both above, I should be able to find something really, but I don't think it can be correct ...


Would you please be so kind to

a. install XX in its current consistent version (i.e. no mixture with other XXEngine3 versions etc., and use the normal 96.dat)
b. act as if you didn't post anything about this yet, and explain as accurate as possible what does not work, and which works in Foobar WASAPI.

I really want to (and will) help you, but currently I am lost a bit.


PS: Your idea of using an old XX version in order to try, is actually quite good. But, you must use consistent versions always (I mean : as how they can be downloaded), and when such an old version works it really could be useful to know which one. But please don't do that right now because I first must know the exact situation at your side from the current version.

Ok, so now I understand better.


But this was with the before sent 96.dat, right ?
Or is it also with the one that normally belongs there ?


Please check whether your earlier post is correct, because that tells about xxengine3 stop working at 24 bits ... :

Thanks for trying (here it works with that "other" 96.dat at 16 as well as 24 bits).

There is something I don't understand;
It would be my idea that when the soundcard (towards XX) rejects the 24 bit modes, you would not be able to even start playing 88K2/24 (actually 88K2/32 which would happen at Doubling/Upsampling). However, you told (first post) that the 88K2 lamp on your processor lits, but the sound is distorted. This tells me that you must have selected a DAC Is setting with 16 bits. Can this be true ?


JFYI : I don't think it is reliable to check this by looking at the latencies. Best would be (99% sure) to try to switch of the sound by means of the loudspeaker icon in the taskbar tray (rightclick - Open Mixer) and the icons and sliders in there. Here this works okay (Foobar), but then I feed everything with data of which I know it can be handled without conversion.


PS: Don't forget to set back the original 96.dat.

I have been pulling my hair what the difference could be, and I came to something ...

Because the whole Exclusive Mode thing is so buggy I applied quite some tweaks. One of them is contained in the 96.dat file which resides in the XXHighEnd folder. Now :

Keep your own 96.dat safe, and put the below one in your current XX folder. It "untweaks", and should normalize things far more to the Foobar situation.
Please note that the normal behaviour is that the nearest possible samplerate and bit depth is selected when the one needed is not there. It would be normal if Foobar does just that, and keep in mind that XX does *not* do that (because it would imply a conversion).

The first thing you might do is run the DAC Test and see whether there is any difference.

Do not forget for this XX version (0.9v-3) that you replaced this 96.dat file, because it won't allow you other things;
When it helps, I can make it dynamically.

Peter

You are right. This is wrong in XX. On the other hand, I am 99.99 % sure that being able to set it to 24 bits won't change a thing. But :


... I hear you saying this too of course.

I will fix the error of not being able to set the DAC to 24 bits (in your given example) and then we must see further. But then again :


This should tell me enough. Or IOW, when Foobar allows something in this area, it resamples first. Maybe you remember that at some stage I quit allowing resampling by the OS because it just would be for the worse. Thus, XX doesn't allow this now, while WASAPI actually does allow it.

But to be sure (for me) : do you have information that your soundcard/DAC supports 16 bits only ? because if so indeed, we just might wonder how Foobar seems to manage ... 

Yeah, but although that might help you, it isn't the solution to something which just should work from the beginning. Most important of course is if Foobar behaves the same in all aspects (about your resampling to 48K first maybe). Because if not then it's apples and oranges.
Please keep me posted !

... which would be true if it didn't work here or with others either, but it just does ...
However, might you be in doubt, tick the AA checkbox, which would give your SSRC resampling (loading takes long then).

Also, depending on the type of file you use, unticking Enable Crack Detect is a good thing to test with in this case (supposed yo played DTS or something like that).

Anyway, I just checked out Foobar, and indeed I can't find anything wrong with it (at normal 44K1 play and upsampling to 88K2 via PPHS resampling). So it wouldn't be in that area. I noticed something else though ...

I took these 30 minutes to checkout SQ of Foobar now, and at noticing some remarkable differences (not in favour of Foobar hehe) I started setting the parameters concerned. This pointed me at the minimum buffer size of 100ms, while XXHighEnd uses 1ms - 270 ms depending on combinations of settings. Now :
The Foobar buffer in Playback - Output does not act the same as the buffer in XXHighEnd I refer to BUT at using the Foobar buffer at e.g. 100ms for sure you would feed the audio chain with something which is much more "at ease" than the XX buffer at in fact any setting.
To work as stressless as possible in XXHighEnd you should set the Q1 slider to a higher value (but too high and it doesn't work anymore (skips and things). And I see from your sig that you use a Q1 of -4, which is the most stressful setting (but generally with the best sound !) and which for sure not everybody can use ! (ticks, distortion).

Looking at the input buffer at the soundcard, I couldn't find differences between Foobar and XXHighEnd; both need 96 (+ 64) samples of buffer in order to play 88K2/16 (I didn't try 88K2/24 btw). Both can use 48 (+64) samples to play 44K1/16. So at that end both are as "lean" which btw (to me) is obvious for WASAPI playback (at that end all is the same when talking about achieveable latency).


Can you do something with this information ?
Please keep in mind that I'd do anything to solve this for you, because if "some" WASAPI player (that's what it comes to) is able to work with a soundcard, there's really no reason XX shouldn't do it too. We must only find out what causes it not to, ok ?


PS: There's so many things involved that it's easy to forget one; It just slipped into my mind that XXHighEnd would be upsampling to 24 bits (actually 32 bits) ALWAYS as long as the soundcard supports it *and* you told XX that the soundcard supports it. So note that when you'd upsample in Foobar to 88K2/16 there's twice as less data going through opposed to XX which will output 88K2/32. When you want to test this, set your DAC = to 88K2 (or 96) / 16 bits (or make sure you play Foobar at 88K2/32 (padded)).

PPS: I hope I make sense to you ...

Hi,

I have a question which may look unrelated at first glance, but it very much is :
How can you tell that the output from the plugin is 88K2 ? Most probably you can't, meaning that it is possible that the OS resamples for you (and *then* the output to the processor is 88K2, but in a unintended way).

To me something like the above would be the only explanation *unless* I am doing something wrong with the upsampling (but as you probably know this is finished for quite some months now, and I don't hear anything about it (including from myself ).

A test which might give an indication, is checking whether Foobar output is in Exclusive Mode (if you know how to do it).
In the mean time I will investigate Foobar myself; wanted to do that anyway.

Peter

PS:


Officially this is so, yes, which is related to the picture being visible a.o. in the right pane. However :

1. I did all I could think of to free everything around all the pictures and it doesn't help a thing;
2. I found that it just needs x attempts and then it works.

For those who really love bugs which can't be solved :

The 174 times I mentioned are 9 out of 10 times exactly that (meaning : not 173, not 175 but exactly 174);
Any sleeping time before the attempts do not change a thing.
Changing the sleep interval in between the attempts (my 4 ms) doesn't change a thing.

It took me a Saturday to work around this (like it is now), and it is the strangest bug I've ever seen (because of the behaviour).
Can you imagine that it took hours at first before I started to perform the Renames in a loop ? ... the one attempt just never worked, so ... it just didn't work. I thought.

Along with this goes the extremely annoying long wait times in Vista at deleting / renaming / copying files and folders, which (note !) is not about the renaming etc. itself, but about the windows showing the time it will take that stays there for 30 seconds while the real work has been done already, but won't allow you to proceed anyway. I say "along with this" because I couldn't solve this (as the whole world can't, but usually I can hehe) and it caused the really very first time in my whole life for me to re-install the OS to get something working again (and Russ, I think you know my TT stories). It's just in the same area.

Btw, the latter problem does not occur when operating the files from another PC.


100% sure this is incurred by XX itself, because the same happens from within the Library Area, and there it just works for already a long time (although I didn't try it lately).
With Delete it is exactly the same (and that too is performed in a loop).

Lastly, for the real insiders : I use an old version of the Rename (meaning the Rename command from VB) and not the official dot-net version. The latter behaves even worse (takes 1000's of attempts), which tells me that something fishy is going on with the "Managed" part of the code (managed : dot-net determines when to free memory really, and this is not up to the programmer).


Anything else ?

Dear Burgermeister,

The Rename issue is known to me, and I thought I mentioned it in the Release Notes (maybe not) (this is about the Renaming in general). This is a bug I couldn't resolve, and as far as I have seen this is Vista only (honestly, I tried over the network renaming files on an XP machine, and there it works flawlessly.
So FYI : on average it takes 174 () attempts to perform the Rename, and those attemps are built in at a 4ms interval 3000 times max. Btw, this looks very very similar to Vista file management in general, which bugs half of Vista owners. I had it too, and there was really no way I could get rid of it. Upgrade to SP1 didn't help (which helps 80% of people), but a reinstall to SP0 did (note that I didn't have this right from the beginning).

Re the old items in the Playlist, yes, of course. I will solve that (I should receive some lessons on how to become a user ).

As always, thanks for reporting Russ,
Peter

Ok, for those who are bothered by the network reference bug, below is the intermediate version 0.9v-3a (XXHighEnd.exe).
Unzip it to the folder where 0.9-v3 resides.

Russ, FYI : it went wrong at the official dot-net retrieval of file association icons from the OS. To me this is kind of logic because the OS would be another one (another machine anyway). Now a routine I created myself does this job, and I hope it's official enough to cover for all situations.

Also, I found the relatively very slow response on retrieving CoverArt Data at clicking on a Library Item was caused by some time-lag in the (Vista ?) OS, which I worked around. Note that this makes the Fast Rendering checkbox (Settings Area) less valuable, because the real time was taken by this time-lag.

Lastly the Rename to Folder.jpg is in there.

Here's a little brainstorm (merely for myself) in order to find what's going on here. See the bottom under the double line for more to the point stuff.



I read this again, and I thought that at clarifying a bit from my side, you can better determine what is going on.

The XX.dat is normal and it is used internally a.o. to keep track of what you played (in the end the data in that file goes to !Played.PLXX). FYI, this must go this strange way, because remember, Engine#3 is running (or can run if you want) completely on its own and it does not take care of playlists etc.; it just plays.

The XX.dat is held in your current XXHighEnd folder (not the by you appointed Data folder !), that is, I wouldn't know of a way to let it end up elsewhere.
One exception to this : when you'd be able (but are you ?) to start XX by means of file associations (double click on a music file from within Explorer), yes, then the XX.dat would end up in between the music data.

The latter not assumed, what you look at in the (right) CoverArt pane just *must* be the contents of your current XXHighEnd folder. Or at least, partly (for the XX.dat part). Why "partly" ?

... because the XX.dat can't be somewhere else than in the XXHighEnd folder, and because the Folder.jpg shouldn't be there.
The latter is a bit more difficult to interpret, because most probably it just *is not* there, but, what you see in that right pane is just everything XX found for coverart data. Btw, with richtclick on such an item - Show Location you can see where the files really are.

Generally you can say that XX looks for coverart for the current album in the folder of that album, one folder above it when it's a multi volume (the name of the album one folder up), and all the folders below the folder from the album. Knowing this, we now can look again at the structure I gave you :

D:\
  \Music
    \Album1
    \Album2
    \XXHighEnd program

by mistake I had Album1 twice in the earlier post)
and actually all should be able to cope with this (so this example is wrongish). This sure would not work :

D:\
  \Music
    \Album1
       \XXHighEnd program
    \Album2

because Album1 would come up with the data files from XXHighEnd.

I assume that you sure do not have a structure like the latter because

a. it wouldn't explain why all your albums don't work;
b. the XX.dat can show up only with Album1;
c. there's a lot of files more in the XXHighEnd folder.

So here's my conclusion (for now ) :
You must indeed be starting XX from explorer and file associations, because then the behaviour would be so that each album shows the XX.dat.

But then I don't believe you do this, because
1. this was discussed before (which you know) and it doesn't work really;
2. (I think) it would be too much hussle at a new version.

What can I conclude more ?
Well, apart from nothing, I recall that I saw the XX.dat myself somewhere where it shouldn't be. And let's keep in mind : the XX.dat only should be in the current XXHighEnd folder, and nowhere else (also, XX so far never wrote anything to your precious source folders (but that will change in the next version haha), which I really wouldn't dare without telling). But ... it can well be that somewhere there's a mistake in the program ...

Ok, at this stage of my reasoning, I suddenly realize that XX.dat doesn't even exist anymore in the program. So, what you bump into (must be "here and there") is from a very old XXHighEnd version (November 2007 or earlier). So here we go ... the whole thing is unrelated, and the subject is invalidated.

---

---

Now I REALLY don't know.
The capital F doesn't matter (but I will look whether I made a mistake into that one).

Maybe it makes a difference when you tick Simple Search (Settings Area) ? It shouldn't matter, but at least then the only thing which is (and explicitly) looked for is folder.jpg, which also is equal to before 0.9v-2. When Simple Search is not ticked things are way more complicated and everything could go wrong ... weren't it that here I don't have a problem with it.

Gerard, forget about my earlier questions, but please try the Simple Search checkbox and let me know.
Thanks,
Peter