Track length

[JohanZ]

Hi Peter,

Today i have made some backups of cd's with a length of 60 minutes and more for one track. When i start the track to play nothing happened during 2 or 3 minutes and then an application crash. I have test some other cd's all the same. When i play a track of 30 - 35 minutes all is then working ok. Settings are no double, no quad, no upsampling, 16 bits cd's, EAC, i am using 3 GB of RAM memory, PCI Soundcard,

When i use double for a track of +-15 minutes it gives also an error.

What is the maximum track size to play Capless between the two tracks?

I have upgrade the RAM memory from 2 ==> 3 GB. Is XXHighend using this new memory?

Regards, Johan

[PeterSt]

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.

[PeterSt]

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.

[JohanZ]

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).

Indeed thats the solution!

But when i forgot to use the right setting (no double or mem checkbox ticked), i get a application crash. Is it possible that you automaticaly downsize the settings so that the music keeps playing. Or make a tickbox "Downsize automaticaly when needed" Otherwise generate an warning message. E.g. you do when 24 bit resolution 96kHz when you use the double setting=> Double not supported .......

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

The 3G is indeed used by the system!

[PeterSt]

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

[JohanZ]

Hi Peter,

I guess the answer is No.......

At least you can prevent an application crash, by generating an warning message!?

Johan

[PeterSt]

Hi Johan,

Of course everybody who wants something like this is right. However, so far I want to avoid this because it will influence sound (or maybe I should say : it most probably will and I *really* want to avoid SQ influences as long as I can, since I think currently SQ is the best). But I can also say this :

Although the "crash" like this doesn't look nice, it would really come down to something which works out exactly the same : stop Engine#3.

Please hold on to when I applied the "smart cutting" as I mentioned; at that moment the problem of "crashing" won't be there either. Ok ?

[JohanZ]

Please hold on to when I applied the "smart cutting" as I mentioned; at that moment the problem of "crashing" won't be there either. Ok ?

Great!