After months and months of glueing the bits and pieces of a sheer impossible job : let Bill Gates stay out of dot-Net Memory Management, it has been done.
Officially impossible, but done anyway.
Note that this actually was a theoretical attempt for the better (quite some work indeed for some stupid theoretics
) and the
theoretical result can be seen on the cpu graph (not the meory graph). If you know its behaviour a bit, look at it again ... No, Core Appoinment is still active ...
Might you have a Fireface, look at 96KHz material too.
Well, what's in in for sound quality ?
hehe ...
That's up to you.
Cue Files so far did not play in the best (for SQ) possible way when 32 bits were output, which was because of the size of the native one WAV file. Now they are.
In the Settings Area there is a new parameter "Allow Format Change" which defaults to No (unticked) causing the same behaviour as before.
When ticked though, now two subsequent tracks with a different format (like 44K1 vs. 96K) will just play without interruption.
Caution : Although you may like this, please think twice before you use this option; First of all your soundcard/DAC may cause a somewhat louder tick when the format is changed, and although this is not related to the way this option works (at all), it may come to you (and the family) unexpectedly. If your chain doesn't suffer from this, go ahead. But :
Also keep in mind that when your soundcard allows for changing its buffer size, you may have set this as low as possible, which you most probably will have done for 44K1 files. And, as you will know, this smallest size does not allow for playback of high(er) res files, and without highering it, a (not way loud) noise will appear. It is obvious that when you set the buffer size low for its good purpose (better SQ), you don't want to set it higher to let this "Allow Format Change" option work. Leave it unticked in that case.
It was found that the scale of the time bar wasn't right in some circumstances (at Attended Playback), so this was solved.
Although not sure, most probably a 24 bit file played on a 16 bit DAC did not play in the latest versions. Solved.
Along the lines, and partly solved in an earlier 0.9w version, the tick at "gapless" at subsequent tracks or parts of it, has now been completely solved. However :
Something which looks like an MS bug, may cause in between real tracks (so not parts of it) a short repeat of the beginning of the track (though a second or so later) of the track which actually is at its end, and where we should hear the beginning of the next track.
This has been solved with a tweak, but theoretically it can still happen at a very small chance per track, with a net result of maybe once per 3 or 4 albums *and* you must be able to coincidentally hear it.
Note : Copying the behaviour is not the problem (and can be done in 5 seconds time), so if you encounter it, examples are not needed. It *is* interesting though to know if it happens so often that you are really bothered by it. Once per 4 albums already might, and it is up to you if you are. But, the once per 4 albums is just a wild guess, and here it just never happened anymore since the tweak. But it sure can.
Issue still left : A track may be repated unintentionally, after which playback stops.
Note : Here too a kind of "repeat" or anyway an unnatural break is audible when this starts to happen (hence when the track starts to play again). This is not the same as above mentioned issue, but it is of a kind of convenience for you, because it will draw your attention at listening again to the same (which usually takes a minute or two before that is recognized
).
Hope it all works as intended.
