XXHighEnd

---

There are serious reaons to believe that this version is not the best for sound quality. If you are new here and want to experience XXHighEnd for sound quality, please go to XXHighEnd Model 0.9v-7 (http://www.phasure.com/index.php?topic=592.0).

---

Caution : So many things have been changed due to this version -and all are active now, no matter the settings- (see below) that when you are not using a pre-amp and use the digital volume at, say, -12dB or lower, it is the most strongly advised that you use at least two subsequent (!) tracks of playback with other means of volume (additional digital from Windows or analogue) so when the output of XX turns to full scale unintentional you just can report it instead of calling your supplier for new tweeters. :yes:

Those who followed the development on all the variations of samplerates, bit depths, double, quattro, upsampling, Mem checkbox, Low Dynamics, rare FLAC files, WMP impeeded informal header files ... will recognize the infinit number of combinations to test, which also requires quite a lot of source file combinations. Your developer here doesn't all have them, nor is he able to find the time for testing it all. All together you however, do, and most probably someone will be able to find a combination which doesn't work as intended.
Please note that this actually not expected at all, but this doesn't imply you should be warned about it anyway.

Background on this :
Where XXHighEnd is a pure memory player, situations may exist that your precious high quality files just will not fit into memory. Or, will not fit into memory including the "gadgeds" required from playback, like upsampling, playing two subsequent Cue File albums (technically meaning two subsequent tracks of over 700MB each before upsampling etc.) *and* of course the stupid technical aspect of two tracks needing gapless playback requiering those two tracks being in memory at the same time (including beforementioned "gadgeds").
Yea, it's a tough job to be a memory player, and keep this all up.

What has changed :
A normal player may open the file (the track) and read very small portions of it when needed. This "when needed" is most often adjustable by means of changing the size of the "buffer", that buffer being able to hold the portions read in order to stuff it onwards to the DAC.
Although you could say the XXHighEnd now is able to behave exactly like this, this is indeed nothing more than "behave". Technically other things happen, and the "Memory Player" principle still stands. This, a.o., means that now a portion of the track can be read when wanted, but all of the longer existing stuff like not interfearing with the on-going playback still stands, and it stands high !
All together this comes down to the exact same behaviour of treating two subsequent (gapless) tracks, but now the treatment is such that the tracks may seem smaller to the player (XXEngine3 only btw), further not knowing about any difference. One functional difference is there though : when your system was "capable" of producing clicks and the like at the boundaries of two tracks, now this may happen each 10 seconds or whatever you imply by setting the "buffer size" in combination with the capacity the track requires (the higher the net bitrate the smaller the portion which fits into the buffer, the more the player sees track boundaries). All together this requires much more from the player, because you really wouldn't like to hear a click each several seconds, where before you could survive with one per track (if at all which counts for 99% or more of users).

So, apart from being able to play larger tracks (infinitly large in fact) there are down sides only ? sure not ! Read on ...

(the below all explicitly created for Engine#3 -or at least not tested on the other Engines-, unless noted otherwise)

• In the Settings Area the parameter "Split file at size (MB)" is what this is all about; It was already there at 0.9w-1(a) but it was disabled so far.
  
  Important : For your conveniency, this parameter tells how much *net* size of the track you want to me in memory. Net means :
  After all the applied beforementioned "gadgeds", how much will be in memory. Example : a 16 bit file with a 16 bit DAC will double its size in memory when it is Doubled or Upsampled. Simple. However, when you have a 17bit DAC at least, the file will take 4 times the amount in memory because the output will be in 32 bits then (no matter your DAC is still 17). Now, try to understand that when you put limits to the amount to be in memory (see below) the only thing hapening in the latter case, is that 4 times more a portion of the file will be read (assuming it does not fit in the size you set). Thus, this means that from now on the used memory will always be the same, unless the track is so small that it doesn't reach the set limit (uhhm ... together with the subsequent track which has just played, or with the upcoming track).
  
  Since it was found, no matter which OS you have, 2 GB is the limit for one process to use, and assuming that the 2GB are free memory (because you use a 64 bit OS and have e.g. 3GB of memory) you should set the limit to ... 1GB. This allows two subsequent tracks to play -no matter their size- and together (!) they can't exceed the 2GB.
  Btw, the current (useless) maximum is 10000MB (10GB) and the minimum is 12MB. On the latter : please note that this was not tested with 24 bit 352800 (DXD) files, of which the minimum may be too small (!), where the "too small" may incur for synchonization problems between a first part and a second part, and the 12MB taking a too long time to read, hence the system can't catch up once it is behind (hard to explain, but it exists).
  
  The funny part is this : Your developer has reasons to believe that setting the limit to such an amount that the total (!) memory used by the PC stays under "some" limit, SQ improves. Such a limit may be 640MB (think of old days), it may be 1024MB, or it may most probably be the boundary of where "physical memory" flows into the formal area of virtual memory (when you were/are able to follow :Shut off Virtual Memory (http://www.phasure.com/index.php?topic=549.0)).
  Anyway, using smaller parts of the file (like 20MB) seems to sound more lean, as if less troubles are applied by the OS to let things flow. Something to try out for you all, and curious whether we can get an agreement on this. :)
  Besides this, and again referring to the mentioned ticks you might have, those ticks might just *not* occur anymore because of the enourmeously less constraints put to the system, normally needing to read 100MB etc. in one go with right behind that applying the "gadgeds" into memory which is 100% cpu intensive, and which now can be brought down to e.g. 5 times gross (assuming a 20MB limit) meaning ... well, you know, times 4 or more for net. So, achieving a factor of 20 less of constraints is easy to achieve.
  
  So much for the memory player ? haha no. As explained above ... the benefits are still there and are untouched.
  
  
• The principles applied, have been applied all over. This, for instance, means that a track which doesn't need conversion (of any kind) will start e.g. the factor of 20 more quick than before. :nea: you didn't bother for this first startup, which already vastly improved with 0.9v1, but think about changing the digital volume or any other settings that imply a restart of Engine#3 ...
  To give you some insight (on the changes throughout) : when e.g. the timer slider is put somewhere in the middle, this won't imply the reading into memory of the whole track anymore, and just the portion needed is read, starting right at the byte the slider implies.
  No, nothing much for a normal player, but a huge improvement to XX. And, because throughout is throughout, even when you do not put limits to the size in memory, this still applies, because from now on the bytes needed are the only ones read. Thus, starting at the position implied by the time slider.
  
  Note : When conversion is in order, there is nothing to prevent from a full conversion first, which then obviously needs to a. read the whole (e.g. FLAC) file from disk, and b. create a full conversion from it. However, since the latest versions *also* now allow to make use of a "cached" first track, the conversion of that first track doesn't need to be done all over, and mentioned time slider (etc.) changes jusr workout as said, no matter needed conversions.
  
  
• The Cue Brigade saw it coming : this also now counts for Cue Files.
  Additionally though, and following the logic of all, again no matter the set limit, only the logical track is being read into memory, opposed to before when the complete album was read (even per track of it !), usually creating problems at the boundary of two subsequent Cue File albums. Not so anymore.
  
  
• The whole lot at last allowed for "A-B" playing, meaning you can set a start and end time for a track, which repeats the A-B portion infinitly until you stop it.
  Note : At Attended Playback the time slider won't move during this means of playback (and at Unattended Playback you won't be able to see it hehe).
  
  Slide the time slider to the start (A) click the AB checkbox which receives the "intermediate state), slide it to the end position (B) and click the AB checkbox again (now receiving the checked state), and press Play.
  
  
• Additionally to the above, this allows playing the portion of subsequent tracks just the same. In order to let this work, click the "End after track checkbox" as well.
  Note that whereas the AB checkbox pertains its state at bringing up XXHighEnd again, the End after track checkbox does not.
  Kind of important : when you set the A and/or B point so that it is out of bounds for an upcoming track, you are out of luck, and since this was not tested, most probably an error/crash will come from it.
  
  Note that this is a feauture which is applied *after* any meand that filled the Playback Area (hence list of files to play), meaning that it can be combined with e.g. Randomized Playback.
  
  
• During the process, the one sample which was found lost on Cue Files (due to EAC inaccuracy) and which was solved earlier, it appeared that because of the solution to this always one sample was lost for non Cue Files. :sorry: Solved.
  
  
• In the case the above is of not much importance to you, this one might :
  When you just ripped an album (or downloaded it, whatever), it was nothing less than a pain to get it into the appropriate Galleries as well. As you know, the activity is a redunant one, and nothing is worse than redundancy. Although this by itself will stay, a first attempt has been made to soften the pain; from now on, with normal Explorer right in front of you (assuming you just did your best to get the new album right in its physical place) you now can drag the album onto its intended Gallery place in the Embedded Explorer.
  Careful please, and learn the abouts of it (hence create a trial place) before you (too late) find things to have worked out wrongly;
  The way the folder structure is created in the Gallery is exactly the same as it is done by the means you are used to - if you are, but this is selecting albums in the Library Area -> rightclick -> Add to Gallery which creates a logical structure right from the structure you selected in advance by means of the bottom text box there - and where the folder(s) dragged onto Embedded Explorer are the representative of the context of that text box. Try it out, answer No to the questions to create the Gallery entries, and watch the contents of the text box, now being filled automatically where before you had to fill it more explicitly by means of selecting "a" folder.
  Try it out, and you will get the grasp of it.
  
  The way Embedded Explorer behaves is nothing more or less than Vista Explorer behaviour, that being a pain by itself because of opening and therewith moving target folders (when you are not quick enough), and maybe in a next version this can be improved. So, still working on that one.
  
  Individual tracks can be dragged and dropped just the same, and the result is the same as if you were adding a track from within the Playlist Area (rightclick on a track once it has received the full selecetion color -> Add to Gallery).
  
  Important : Currently no provisions are there to prevent you from doing things the wrong way around, meaning that you will be able to drag Gallery files onto real music folders, or dragging real music folders onto other music folders (that resulting in actual Gallery entries within your orginial music folders). So be careful on this, and at least watch yourself. :yes:
  
  More important : More than before this incurs for deleting Gallery Entries from Embedded Explorer when you did something wrong, or just want to get rid of Gallery Entries for other reasons. You should NOT do this, because it will destroy the referential integrity (see the x-Reference files), with unknown results on further (Gallery) activities. The solution to this will hopefully be available in due time.
  
  
• Regarding the above and individual tracks put in a Gallery by means of the Playlist Area -> Rightclick -> Add to Gallery, a bug caused the track name to appear as an empty folder name within the actual just created Gallery folder. Solved.
  
  
• It was found that the Crack Detect feature -created to help you finding out about player (and file) errors- contained a basic error, actually leading to an impossibility in understanding how it ever can have worked properly;
  Of course, some reported Crack Detect which appeared not to be so at all, but on the other hand in those cases this could be explained in other directions. Now please note, that while this has been solved to the proper way of working, it could not be proven to be so because it already worked. However, what *could* be proven is "no Crack Detect" where it certainly should, and the other way around but then by means of new errors in other areas, all together still not proving anything really. So :
  When you now encounter Crack Detect (and which can happen at reading a protion of a file now !) please be over cautious. And the other way around : when no Crach Detect appears, well, see the beginning of these Release Notes.
  
  All 'n all, might you have shut it off because you received too many false Crack Detect reports, please turn it on now, and let me know whether it makes a difference (hence whether it now works properly).
  Users with 24 bit files should be alarmed extra, because the basic error found implies those files to be affected most.
  
  
• The algorithm used to find the proper header data was a. found to be errorneaous in certain situations (not reported, but with own examples proven) and b. not 100% decent in general. IOW, might you have files which just didn't play (while others of the same format do), please try them again.
  
  
• Somewhere in one of the latest versions, a bug has been sniffed in, causing the time slider to be at position 0 always when XXHighEnd is brought up again during Unattended Playback. Solved.
  
  
• Again in one of the later versions, the positioning of the time slider caused a different offset than implied. Even bringin up XXHighEnd and doing nothing but restart Playback, caused the start of the track to be at a quite other position than the slider indicated.
  
  
• Now, when XXHighEnd is brought up during Unattended Playback, and (after changing settings or not) Play is pressed, first is determined how far playback has commenced (note that the track is still playing in this case), and right before XXEngine3 is restarted, the actual play time offset is actualized.
  Note that since the resolution of the time slider is 1 second, you may be one second off (at most, and always back to the past).
  
  
• When a system with a single core processor needed a conversion, an error occurred when Play was pressed (since 0.9w-1). Solved.
  
  
• When right after startup another Tab was clicked than Library, clicking the Library Tab afterall showed Embedded Explorer with a root of "this Computer".
  This shoot be the root as indicated with "Music Root" in the Settings Area always. If all is right, solved.
  
  
• Since the Date Search option was introduced including sorting on it (one or two versions back), several functionalities could not be performed on items showing in the Library Area also showing the Date/Time (selected). Solved.
  
  
• Albums (an on that level !!) not containing Track Numbers preceeding the Track Names, will show Track Numbers now when loaded in the Playlist Area. Besides that, these virtual (proper) Track Numbers will be applied when playing Each Track Number (Library Area, rightclick on an album -> Play Each -> Track Number. Note that this is not applied to "Per n Tracks" in there, assuming that the Track Number really isn't needed to play "Per n Tracks", although the tracks played will be different ones.
  Also, currently, when one track is selected right from the Library Area (Searching with the "T"(rack) option where normally shows an "A"(lbum), the Track Number is not inserted.
  Apart from this exception, Track Numbers should be inserted by all means of loading tracks into the Playlist Area; please report if you find something not working in this area, though please note the below.
  
  Important : Currently, the only means to get hold of the Track Number, is getting it out of the withgoing .cue file (not confusing this with the Cue File phenomenon). Thus, this .cue file indicates the track numbers fro, the album, although the tracks are separated into individual .wav or .flac files.
  
  
• When Track Names were searched for, only one track being the result, an error occurred from "Show CoverArt" telling the path was not correct (similar). Solved.
  
  

Issue found, though not  sure whether is has been solved throughout the process :
At Unattanded Playback it may occur rather rarely that a track is played for the second time, while right after that, playback quits (in a normal looking fashion, but it was *not* the last track);
When you see this, please report, so it will be clear this issue is still there.
Btw, the smaller the set portion of the file to fit into memory, the earlier this may occur, and when the size is set to something really large (like the default of 2500 MB) it will just never happen (it can't then).

Thank you all, and as always, have fun.


Edit : It looks like that with this version Cue Files can't be loaded into the PlayList Area from Galleries. At attempthing this, an error message tells that a part of the path cannot be found, and the PlayList Area then shows one track, looking like c:\[MusicRoot\Album\Track\etc.] which obviously is not right (c:\ assuming the location of the Music Root as set in the Settings Area).

Edit 2 : With this version Engine#1 (and most probably #2 as well) are renedered useless; when a Playlist is started, all tracks from that playlist will play together. Quite interesting, but sure not as intended !!