Hahaha, but that is great ! I always thought that such a "tweak" would be possible somehow, but didn't pay the real attention.
Now think in ADAT channels instead of SPDIF (just choose them in the FF) and start connecting outputs (DACs, speakers, speaker drivers ...).

Although we could say it is too stupid not to see this option in a glance, I say you are great pedal !. So allow me to say it :
GREAT !!

[ Moved a post from pedal Re: Firewire connection ]

I too can choose between USB and SPDIF; besides I agree with your remarks pedal, I could add that SPDIF is more snappy, USB seems to present the bass better, but the most important remark I have with USB is : the musicians don't want to present themselves. I know, a strange description, and I guess it is related to everything being less profound (and volume doesn't help hehe).

Of course this information is useless because of the USB connections being different (and in my case USB is converted to SPDIF internally), but still ...
The reclocking the Fireface does presents an overwhelming 800ps jitter which would be the world record in badness these days. But if I compare my same DAC in a (commercially) presented 0ps jitter (btw USB) version (which XXHighEnd CANNOT influence) ... that doesn't cut it. There's just much much much more going on and let's give it another year to find out. I think we are about to have the tools for it ...

Hi Johan,

Maybe your proposal is not the best idea. I mean, you'd leave the Mem checkbox unticked for the better SQ you expect from it, right ? Now what would happen if the system indeed would auto-use the feature of the Mem checkbox without you actually knowing ? I would go crazy by that, and I'd always be checking - per track - what the status is the system created for me.

The option I have been thinking about though, is eliminating gapless in such an expected situation. But :

It may seem strange, but currently this would be the hardest thing to do for various reasons. The only option I see to implement this within a few hours only, is with Attended Playback. But a. it would be fixed then (hence not dynamically "self investigating") and b. this again would imply less SQ or depency for SQ on XXHighEnd (the GUI) the least.

So I guess the answer is No, because already you yourself wouldn't want this (and I decided for you haha).


No, I think it is better to think about some smart trackloading in the sense of "too long ? then cut in half". All the mechanisms for this are there already, and all it needs is faking a long track into two, which then plays gapless as always. The only downside of this would be that during the playback of the track SQ is briefly influenced (in the middle), which would be the exact same influence (if at all) as at the current normal track boundaries.
Of course a cut in two parts could also be a cut in three parts (etc.).

Peter

This is not true of course, because I didn't upload a new version of that.


Mike, that puts things in another perspective for at least some of your cases. Also, now I have something concrete to work with.

Gerard, thanks. That ChangeWP thing to me looks like a similar problem why the earlier uploaded XXEngine3 didn't work. I need to apply similarly to the ChangeWP.EXE (and another one or two I think). Also this implies that I address the Wallpaper stuff unnecessarily. I will sort that out.

The error you showed at the bottom is due to XXEngine3 still running, which by itself is caused by the "No track given" message not clicked away by you (so, really not a problem, but by itself caused by the originating problem, which will be the ChangeWP thing).

Sorry for that Jack. I sent you an email.

Thank you very much Mike. And for you sig.

Btw, I didn't do anything to solve the problem, and I only hoped a message would appear. Apparently not. Otoh, I sense your problem in another direction as ... yeah, as what ? never mind ...;
Can you please tell me what DAC you use, and what the soundcard (or mobo chip) is you use, or whether you use USB for the connection to the DAC. That is, *if* you use an external DAC.

Thanks again,
Peter

Oh yes. Back, or just newly there ... so true. By now I know the keyword is : noise;

What you need for high efficiency speakers is a buffer WITHOUT NOISE.
So no matter what (never mind the high efficiency) , the drive is needed. The problem is to get that without the amplification of noise.

Had some time to look it up. Here's the "calculation" I referred to :

Re: Accumulative memory --> I'm running out!.

Also look at the post underneath this one. I think for two subsequent 60 minute albums this comes down to 10GB ...
This is non-sense of course, but for one you're still at 5GB.
With the Mem checkbox ticked, 2GB is enough for subsequent playback of two 60 minute albums.

Ok, second attempt. Unzip below zip into the 0.9v-1 folder and allow XXEngine3.exe to be overwritten.

Things suddenly didn't work anymore because I upgraded the development environment (to Visual Studio 2008), which of course didn't show on the dev PC itself.
I tested this on another Vista PC (with SP1 btw while the dev PC is at SP0), and there it works now.

Coincidentally I ran into this :

Sound Device is : SoundMAX Integrated Digital HD Audio.

When this device is used over the "Loudspeakers" (hence no digital out) this can play, no matter we use Exclusive Mode. Ok, before (few months ago) this was logic to me, because then XXHighEnd also addressed Shared Mode. But not anymore now ...
This still works with Exclusive Mode, with the difference opposed to digital out that the Windows Volume can be used (just as well as that the sound can be shut off completely). But, this still will imply bit perfect playback (ok, with the volume at 100%).

[Note : To some of you this might not be news.]

But there's a pitfall;
In my particular case, there is no SPDIF connection for this device. Thus, loudspeakers only. This means that there is no tab in the device's properties with checkboxes allowing you to tick what it should allow (the tab where you can tick things like DTS as well). This by itself is not important, but, it gives less confusion on what does what (or nothing while the options are there). So, in this case there's only the Advanced tab, with the both checkboxes for Exclusive mode, and the combobox showing the possible playback modes of the device (like 44.1/16, 48/16, 48/24). Now, here things become important;

The combobox most often (if not always) shows 48/16 as the chosen setting. This setting - in this case - is the most active;
Obviously 44.1/16 won't play when 48/16 is set. BUT (!) :
When you tried it once with a "wrong" setting (like 48/16 would be), and then set it to 44.1/16, you will receive this :

ENDPOINT CREATE FAILED -> The Dac does not accept this byte sequence
The Device cannot play

The stupid thing is, this message is not for real, or better, just wrong (and I can't improve it btw). It occurs because the device is occupied by the previous attempt, at least in my case it is. It needs a reboot ! But careful now, you must FIRST set it to 44.1/16, otherwise windows sounds will "occupy" the 48/16 and again it won't work.

In brief :
Set the device to 44.1/16, reboot.
Start XX with a 44.1/16 file.

Now for those who receive the ENDPOINT CREATE FAILED message, but with normal digital (SPDIF/USB) out :
I expect the culprit to be the same. I can't test this myself though;
Just follow above procedure and try ...


PS: I tried to reset the device's occupation by all means I could think of, but failed. So if you are playing with this, think of many reboots.
PPS: For devices responding like this, it is most probable that the DAC Test is not reliable. In my case only 44.1/16 and 48/16 are reported, while 44.1/24 and 48/24 should work too (too much hussle to test, sorry -> set the Combobox to something else, reboot, and the DAC Test may show different results).

XXHighEnd uses (if needed) all the memory the OS makes available.
There's a topic somewhere where I calculated the additionally needed memory to let the "pre-processing" work. I don't recall, but wasn't it 4-6 times MORE (hence 8-10 GB)? Anyway too much.
But that's what the Mem checkbox is for. Tick that, and XX is using the old method (which shouldn't sound better), where 2GB can take 60 minutes (of 44.1/16).

You might use Taskmanager to see whether your 3GB is actually used.

Well, I've been looking for over 5 hours on where to add debug info combined with where things could go wrong, and could find one place only that allowed a "silent exit" of Engine#3, meaning the sound stops without message. So, if this indeed is the place we are looking for, two subsequent messages will occur, indicated by the first one being "TEMP ERROR B".

Please note that this does not take into account possible length errors, as implied/indicated in at least one post in this topic (the stripes seem not to match the actual track length). On that matter it seems that the various posts in this topic do not deal with the same problem, which does not mean that the origine just may be the same (the latter depends on the truth of all emerging now again, while *all* those problems a. where there before, b. vanished at some stage).
Might it be so that the workout of Gerard (the post with the pictures) is a problem on its own (meaning *exactly* as how he described it), then I can anounce that *that* problem can be solved by a backdoor solution.

I have been looking carefully what was changed in 0.9v-1, and really the only thing related is the calculation of the length of the track (that's why I excluded this in above alinea). But, this then can not be the reason to let things flaw once in a while in a non-repeateable fashion.

Below XXEngine3.zip should be unpacked and placed in your 0.9uv-1 folder (save the original one). SQ might be different.

This message was built in as debug info, and should inform me that a part of the code is being executed which really should not. However, I just found that there is a one out of a near infinity chance it just can (hence the code is allowed to execute), so I now removed the message.

Thanks for reporting Johan.

and we already dealt by this offline a long time ago