XXHighEnd Model 0.9y (support for 24 bit-only devices, Digital Filtering, more)

[PeterSt]

Edit : The download has been removed due to errors in the install itself. A later 0.9y-1 will solve this. Sorry ...



Not checked for typos.


This clearly has been the longest time you had to wait for an upgrade ever. And no, I didn't take a sabbatical, and instead I think the net daily worked hours on XXHighEnd were more than ever before. What does this mean ? well, for a start this means that you can expect a not so stable product as 0.9x-7 has been; There is hardly a thing which has not been rewritten ...

The far most time consuming subject has been the Digital Filtering, which by itself emerged as an option for the Phasure NOS1 DAC (which doesn't contain any filtering), and the crazy complex means of operation - always related to the time it takes to apply the filter to the tracks in the Playlist, the tricks to make it acceptable for you, and the combination of the other "conversions" being there already - some as a pre-pre process (FLAC), others as a pre process (Upsample, Bit Depth conversions) and my ever stupid idea of applied changes (like volume) coming to you glitchless these days. You can well say I worked a month in a row to get rid of the bugs now coming from this all, and this is only from this Digital Filter thing.

Allright, let's see what has happend :

• Digital Filter
  
  As said, created for the Phasure NOS1, with the explicit objective of being able to choose and change (the means of) filtering, which actually is part of a larger (and so far undone) project where the DAC itself is filterless, theories tell that it can't go without, and practice may indicate whether this is true or not. Practice -in this case- means that the type of filtering must be able to change easily and in fact to an infinit number of scenario's, some probably unknown at this time.
  
  Currently only one filter has been implemented, and there is no means for you (the user) to change the settings. The reason is that without having a 24 bit 192KHz capable DAC which also must be without any filter, there is no reason to use this. So, you could say it anticipates on the future, or my own current practice for that matter. But :
  The filter is available to everyone, and might you have a 24/192 filterless DAC, you just can try it right now;
  Do not use it otherwise, because it will then degrade sound only. If you use it, you should only use it with Quattro and Upsample, and it gets activated when the AA (Anti Alias) checkbox is ticked. There are *no* provisions to prevent using it in other situations, but the results will be unpredictable and the filter is not made for it (it assumes an input rate of 44KHz and output of 176.4KHz).
  Questions can of course be asked on the forum.
  
  Notice that this means of pre-pre conversion has been setup generally, or IOW it now can take any kind of conversion following the same principle.
  
  Current issue : Don't use for tracks longer than 10 minutes or an error will occur after two minutes of playback.
  
  
• Abort preconversions
  
  Although we could use it already always, with the long time taking of applying the filter, it really became necessary to abort the process of preconversion. Thus, when you start playing a Playlist (Unattendedly) and your tracks are half way at converting, you can now click Stop and (playback stops and) the conversions will be aborted.
  
  Important : because converted tracks are "cached" hence the resulting files can be re-used when they are asked for in the same session, the result may be unpredictable when the conversions got aborted. Generally this will be no problem, but since the conversions (hence programs doing that) are killed the hard way, files can be left processed half way. Of course all the cached files could be thrown out due to this, but this would not be what you want in all cases (wait again for the conversions etc.). Now :
  
  When you want to get rid of the cached versions, quit the player when no Playback is going on, and restart. Note that when Playback is going on (like with Unattended) quitting and restarting does nothing to this matter. Cacheing with Attended Playback usually affects the current track only, although situations can be thought of that right after Unattended Playback of a Playlist which is stopped half way for playback - and continued Attendedly, cached tracks can be used there too.
  
  For you it might be good to know these ins and outs a little bit, because it is here where major changes had to be applied, and all sorts of applications may work out differently and could be buggy. One example which is currently an issue and related to this, is that most often the current playback position is not known at Unattended and bringing up XXHighEnd. This depends on whether the source is a FLAC, whether the FLAC is a Cue File, whether Copy to Standard XX drive is set ... etc.
  
  
• Split Cue File Tracks
  
  With the Digital Filter as the base reason, now Cue File tracks are physically split into individual temporary files. By itself this goes unnoticed, weren't it that the speed of conversion has drastically been increased, although this depends on what there actually is to convert. But for example, if the Cue File is a FLAC at the same time (so, one large FLAC with a .cue file of the same name), the FLAC file is converted to WAV first, is cached by itself might another track come along to play, and next the files itself now can be cached (is it needed another time, then it is still there in physical form). Before -although slower- this wasn't so much noticeable, but when the (filter) conversion of a 10 minute track takes 1 minute, you start to know - and want better. So, all has been done to increase speed and keep it workable, no matter all has to be read into memory first.
  
  Note : It is imagineable that Cue File users may think that because of this splitting SQ is influenced. This is really not so because before (in the latest few versions) the tracks from the large file were read individually anyway. So, the only thing canged here, is that they are now read from separate physical files, where before they were read from one physical file at the proper offset (start-end), the large file each time being opened and closed when a next track was needed.
  
  
• Support for 24 bit-only devices plus HD Audio devices
  Important : An Audio Device that supports 24 bit ony (example : Empirical Off-ramp, Benchmark USB) needs the setting (DAC Settings in the Settings Area) "At > 16 bits the DAC needs" : 24 bits.
  Although this setting has always been there and was supported by the software partly, it never worked because of special "initialization code" needed, and this code wasn't there (see below). Now : from now on this sure does work, but it means that you can not choose this for fun. Do so anyway, and chances exist you will receive tweeter blowing static, when nog analoguely (!!) attenuated. However, in most cases you will be receiving a message telling you something like "format is not supported", and that (now) depends on the played file whether such a message may appear or not. This means you must try this very carefully, and always assume a DAC Needs of 32 bits in the first place. The devices needing 24 bits have just been about listed, but there will be a few more (Terratec is candidate). Trying carefully means : always use a preamp at testing and set the volume of that to near nothing. Play a track, and when no messages appear, slowly open up the volume; you'll hear whether things are right or not soon enough.
  
  And for everyone : almost everybody will have the experience of the HD Audio Device not working (it's on nearly all laptops) and they use 32 bits. So, don't try such a device at thinking "ah, there's this 24 bit device support now, let's see whether it now works", because it had quite another reason not to work. Here too : see below.
  
  One more thing on this : At a new version, and when the Settings could not be restored, the default will be "DAC is 16 bits" and "DAC Needs" will be unticked for either (24/32 bit) setting. Now, at changing "DAC Is" (probably to 24/96 for such devices) the default for "DAC Needs" will be chosen for you to 32 bits. For "you" owning that 24 bit-only device, that will be wrong, and no warning or such will be given. Thus, always keep this in mind, especially when you don't play with a pre-amp, and can not analoguely attenuate (doing it digitally does *NOT* help).
  
  Because WASAPI always has been so buggy and no real judgements could be made from devices not working for XXHighEnd, it actually always has been a problem to use some devices, and the cause was thought to be WASAPI bugs. However, with great thanks to Mr. Don Colonne who sent me such a not working device (an Empirical Off-Ramp) all over from Canada, I could at last physically test such a device, and found the problem afer a few days searching. It certainly was a WASAPI bug indeed, but which bug only occurs at doing some strange things, like being a memory player which inherently doesn't allow for avoiding those strange things unless you know and sit down for another week to solve that. From this it was learned that HD Audio devices (probably all using the same driver) could be approached similarly, and then work too. But category of devices are very different though, and HD Audio does not incur for 24 bit-only.
  
  If all is right, all audio devices imagineable should work now. So if not, report !
  
  This caused all the preprocessing in the audio engine to be rewritten, and for parts even the audio engine itself. However, this latter only influences the Mem checkbox (use less memory) and LDN checkbox (apply less dynamics) which both have been removed from XXHighEnd, so the code concerned could be removed, and hoping that nobody would use that anyway. A few notes on this, and sound quality :
  
  The Mem checkbox was introduced for those without enough memory to load large files, which become larger when upgraded to 32 bits and even become more large when Upsampled. So, indeed some people may have been using this and benefit from it. However, since files can be split into smaller portions ("Split file at" setting) which has become a standard means, just necessary for the real large files - and including the "SSD facility" and the setting "Standard copy to XX Drive", it really needed elimination of the redundant code needed for this, knowing that the 24 bit-only devices would double all the code. So, if you think you needed the Mem checkbox, please ask questions on how or what to do now, because it really has gone and won't come back. And to keep in mind : the upside is always that SQ will improve in avoiding it.
  
  The LDN checkbox could be useful to those who really thought dynamics were too high. And, although this still can be the case, it is the sincere finding that that this ever was caused by just a wrong means of playback, but, in combination with a DAC prone to over expressing dynamics (which would come down to improper filtering). It is assumed that just nobody ever used this checkbox really, and since this too incurred for redundant code, it really had to go.
  
  Lastly, although you didn't know or perhaps couldn't tell, a few combinations of playback played in that redundant code, which (as just told) also wasn't the best code for SQ. These were untouched 16 bit files but with attenuated volume onto a 16 bit DAC, and 24 bit files played onto a 16 bit DAC. All whatever combinations now play in the same playback code, and everything now is arranged for in the preprocessing.
  
  
• Because of the necessary changes due to the 24 bit-only devices, it now has become impossible to let the DAC Test work. On the other hand, no real reasons exist anymore to test the DAC, which merely has been an option to find out why the DAC wouldn't work with Engine#3 (WASAPI). In other words, all DACs (sound cards) should just work now, if only the proper option has been chosen (16 bits, Needs 24 bits, Needs 32 bits, see above). Of course it would have been handy to let the system show which setting to set (again, see above), but it just can't be done anymore (read : it can't be done reliably anymore).
  
  
• Changed behavior of Crack Detect
  
  Due to the reorganization of the preprocessing, the "Crack Detect code" has been changed from a two pass process to a one pass procesess;
  Before you could say that a native file was checked to be okay, and after the preprocessing (like applying attenuation) another pass occurred (both separately reported), while now only the last pass is applied, and any reported cracks now can't be judged to where (why) they occurred. So, this can be because they are already there in the native file, or because the pre processing code flaws. No big deal hopefully, and at least it saves some time in the preprocessing stage(s).
  
  
• Change of SQ ...
  
  Yes. It is expected that SQ has changed, but for the better only. Partly this is because "not-so-good-code" has been eliminated (see above), but merely (when you just didn't touch that other code) this is about the few lines left comprising the audio engine have been changed.
  
  
• New supported formats
  
  At some stage it was found that by itself valuable downloads are created and presented as mono (i.e. one channel) 24/44100 files. This is about hundreds of preserved and digitized cylinders from the 1915-1930 era, and it seemed nice to support that.
  On a side note : when you know what this is about, well, you will know, but you may also know that these files are not for download, but real time listening only. They can be downloaded though once you know how, and if you're interested please let know via a PM. Nothing tells that downloading is prohibited, which presumeably is a little different from putting it right in the open and let Google find it.
  This clearly is unique material, and XXHighEnd should just be able to play it.
  
  Being on the 1 channel path anyway, if all is right -but sure untested- all formats are allowed to be 1 channel now (most probably except 24/352.. Notice that 1 channel files are transformed to 2 channels, both containing the same information (so, two channel mono).
  
  Although WASPI doesn't support it, 22050Hz (1 or 2 channel) files can also be played now, by applying the trick of Doubling them. Thus, tick Double and play the file. Done.
  Notice that ticking Quattro will play the file just the same, but that this actually implies the normal Double. So, at Quattro such a file will play at 88200.
  Keep in mind that this does not imply Upsampling, but this will work just the same, when Upsample is ticked also.
  This will probably also go along with ticking the AA checkbox (for the filtering), although this was not tested.
  
  
• Analysis ... not
  
  You may discover the new tab for Analysis, and although this has been one of the major reasons for the 0.9y series, it is all not active yet, and maybe it even never will;
  
  As you may know, in fact much effort was taken into measuring the real merits of settings and changes to them, as well as showing the audible differences that different players carry. As you may have seen, the results from these efforts are really there, so you would say "come on then". However ...
  
  During the process it was learnt that some not thought of parameters are applicable here, and these parameters are 100% important, but in near zero cases available to you. This is a.o. about the means of recording and the necessity of clocks needing to be connected (between ADC and DAC). Also, and this was the most not thought of, this is about the DAC needing to be filterless, which actually isn't even the good way. Well, officially.
  The latter is the most hard to explain in brief, but what it comes down to is that what's fed to the DAC, the most oficially should *not* come out of it. This is the area of filtering and what that should or should not do, which also is related to how filtering should be applied at the ADC (thus, at the recording, like how it happens with normal recordings). Summarized you can say that any comparison by "absolute means" (compare a recording with the data file) is worthless, because there is more to it then just comparing *or* it is just not allowed to do (the votes are still out on that). The relative means (compare two recordings) still work as intended, and nothing is wrong with that, but we may question ourselves : what to do with it, and might this not be just a gadget.
  
  Anyway, for now it is at rest a bit, and throughout time it may be reborn. We'll see,
  
  In the mean time XXHighEnd got recording capabilities, but at this moment there may be not so much desire for that. But if there is, it really works, can save the file and all, so shout it outloud, and it may become active.
  
  
• Glitch Detect
  
  Part of the Analysis was the Glitch Detection, and although this does its job, its current status is unchecked and in the mean time maybe bugs are in there. Select the albums in the Library Area to check for glitches, rightclick and choose Analysis - Glitching.
  
  ... or better don't, because you will find many many of your albums just being worthless. When you don't want to know, don't use it !
  
  The point is : it was created to detect errors in your rips, but unveiled errors in the digital process of making the CDs. You will see it; odd sticking numbers of 256, 512, 1024 ... they are plain wrong (because of the nice numbers), and not due to bad ripping. When you see something like that, you might want to put it forward on the forum and ask questions about what you see. With some experience, you will be able to recognize the sound coming from whatever it is you will see ...
  Have fun.
  
  
• Different colors of the OSD running time
  
  As you may know, some commands allow for changes during (Unattended, but also Attended) Playback, which come through glitchless. This may be change of digital volume, change Invert;
  At Attended this is indicated by the green bar at the left (green On -> command is being processed, green Off -> command has (almost) been processed), and at Unattended there are some indications by the change of color of the running time;
  
  Yellow : The command has come through, and is normally processed. When turned into read again, it has been processed.
  White : The command has come through, but the audio engine is busy at loading a new track, and you have to wait for that first.
  Green : The command has come through, but the audio engine is busy at loading a new track part, and you have to wait for that first.
  
  A few remarks go along with this :
  When you see nothing change for a too long time (the time keeps on being shown in read and normally it would change color within 2 seconds or so), something is really wrong. Besides your remote might not be working (but test it with the keyboard commands), the command didn't come through, usually indicating something nasty going on at a later stage. This might be the track suddenly ending, skipping back to the previous track or otherwise, but something just *will* go wrong lateron. If it doesn't, it just means you didn't notice (like the track skipping back a minute which is more hard to notice than you might expect). But :
  
  Having said this, the anomaly is always related (or nearly always) to the earlier discussed cacheing, and the result of it will be that XXHighEnd starts to reconvert a track which already has been converted. Now, when that happens, other things will go wrong as well, but what is quite unpredictable (it may start with the PC being very busy at long conversions like the Digital Filter would imply). And thus :
  Because it can be recognized when this goes wrong, a provision has been built in which checks for this. If it happens, playback will stop instantly, a message telling so. This seems worse than let go something wrong unnoticed, but on the other hand it gives a better opportunity to just notice it, report it, and let it be solved. So please report when you encounter it, and know that these things can always be repeated as long as you know what you did, which will be very much particular track (and conversion) related, and when you gave the command. And yes, it may even be so that giving one command on track one, and two at track two, only after this last command something goes wrong.
  
  
• Changes come through at Wallpaper change
  
  Unlike before, when now the Wallpaper changes the command or new track came through right at that moment (there may be a very slight offset because of the time it takes to build and show the Wallpaper itself).
  
  Please note : while this is a quite unnecessary change, it really looks better like this, and one of the annoying things got rid of this : the Wallpaper changing to the new track some seconds before the track actually ended, that emphasized by the running time, really not switching to zero yet. Now, the downside of it, is that happens at another place in the code (no, you won't care less, but) which interacts differently with the environment, and it may be so that you now have hickups where before you had not. Of course all has been done to take care of this, but the PC here is not your PC, and while many many hours have been spent in the past to get these kind of things right (with much of your help) this a kind of has been eliminated now. The real message is : don't worry if you now suddenly have hickups or the like, but please report them with an as accurate description as possibe, and with the promise that if it takes too long to get right, we'll revert to the old situation regarding this.
  It also can be that it just solves hickups for you and please report that too ! (so a simpel revert won't undo the good for you).
  
  
• There's a new checkbox "OSD Text" in the settings area, and when ticked, it will show OSD the Album Name and Track Title.
  
  Note that "Album Name" so far remains as not much worked out as before, knowing the XXHighEnd is capable of showing a much better Album Name than the Wallpaper comes up with. Might you have no clue what is meant by this, then you will recognize that the Wallpaper does not show Track Numbers, while XXHighEnd just knows them. So, this is still to be worked out better.
  
  
• Define the Height of the Wallpaper instead of the Width
  
  As how it was some time ago, now the size of the Wallpaper is defined by defining the height again;
  Defining the Width turned out to be just wrong, and e.g. DVD cases wouldn't fit the available height.
  
  
• New checkboxes for showing the Back and showing the Mirror Back
  
  Both (Settings Area) can be ticked or not, and each has its own purpose;
  
  When the Back is unticked, this just means you will never let show the back, even if a back.jpg is there.
  When Mirror Back is unticked, this means that you never want to see a mirror of the front.
  
  This really says it all. But maybe it needs a small additional outlay by example :
  When the Back is ticked, and no back.jpg is there, the Mirror Back will show when Mirror Back is ticked. Otherwise no back (area) will show.
  When the Mirror Back is ticked, but a back.jpg is there, and Back is also ticked, the back.jpg will be shown.
  When both are unticked, only the front cover shows.
  When Back is not ticked and Mirror Back is ticked, the Mirror Back always shows.
  
• The font of the Mirror Back has been changed to Verdana
  
  Yes, it could have been made into a setting, but the idea was not to spend time on that right now.
  You can judge for a while whether you like it. I guess not.
  
  
• The currently playing track is always visible now at the Mirror Back
  
  When the active track approaches the bottom, the tracks shift up, and the active track keeps on showing near the bottom.
  When more tracks exist above the top of the list, a ^^^ line shows, and when more tracks exist under the bottom of the list, a +++ line shows.
  
  
• Bug solved on activating unknown service on XP
  
  It appeared that one of the services prone to shut off on Vista, was addressed on XP as well. This has been solved now.
  
  
• Library button has been changed to Explorer button.
  
  "Library" as such was confusing (with regard to the Library Area), and what it really does is starting Explorer ...
  
  
• New (rightclick) option "Explore" on Library Items and Coverart at the left
  
  As it says. Very convenient at looking for anomalies with regard to Coverart, file type (and what/how to convert) etc.
  
  
• New (rightclick) option "Save to Gallery" on the Coverart at the left.
  
  Saves the complete album to the indicated Gallery, and (!) not only the tracks loaded from it in the Playlist Area.
  
  
• New (rightclick) option "Show Embedded Explorer here" on Coverart at the left.
  
  Shows the Embedded Explorer without the necessity to go to the Library Area, therewith allowing to drag files from the Embedded Explorer onto the Playlist Area.
  
  Also : New (empty area rightclick) option on the Embedded Explorer "Show Coverart here", to switch back.
  
  
• The Embedded Explorer can be dragged downwards unaccording the size of the Coverart
  
  Asked by quite some people, and indeed the most convenient. Really a diffence of "so what" vs. "great !". Thanks for keeping on asking !
  
  
• Speed of scrolling through the Playlist Area improved
  
  Or better : As how it ever was, "touching" a Playlist Line incurred for opening the file of the track that by itself needing access to the original file and disk it resided on, that waking the disk up, that making you wait ...
  Since (a few versions back) the Coverart can be taken from Galleries (and of course assuming Galleries are being used) there is actually no need to get to the original location because the Playlist together with the Gallery contain all to do/show as long as actual Playback is not in order.
  One issue left : when XXHighEnd is started (not counting the reason "for a remote command"), the first highlighted track is accessed at the original location. So, when you e.g. start XX for the first time this day, it needs the wakeup of the drive that track resides. This will be solved.
  
  
• Playback with showing Wallpaper kept original disks alive
  
  Unintentional of course, and caused by the Wallpaper functionality that a. got the coverart from the original location and b. got (when applicable) the cue information from the original location.
  Both are derived from the Gallery now (when Galleries are used to obtain the tracks from).
  
  
• Browsing the Library Area faster
  
  The approach for finding the "one and only" front coverart file has been changed by ... eliminating near all of the intelligence which was in there. It really took too long, and in the long run it isn't worth waiting for this feature each and every time, while you can also rename your front coverart to folder.jpg.
  Some intelligence has left, but the most time consuming stuff has gone.
  
  
• New rightclick option "Save as 500 x 500" in CoverArt Area (rightmost pane)
  
  When coverart is too large, it is unavoidable that it takes time to process. Much has been improved already, but too large is too large, and actually "too" is more than you will ever show on the screen. Note that this is about the Coverart showing in the Library Area foremost (which will be the front coverart) and the Coverart Showing in the Coverart Area is only slowing down when asked for (like click on the Coverart in the Library Area), and this is acceptable (*and* useful, because this can be about booklets you want to have readable on the screen !). So :
  When you find yourself with 3000x3000 or whatever scans of the front cover, this new option saves it to a nice 500x500, which is very good for showing as Wallpaper (even if you show the Wallpaper somewhat larger, you won't notice much difference). Note that at using this option the old large file keeps on existing, and after the new one is there (with a name like the old one with a sequence number added), it only takes renaming the old one, and rename the new one to folder.jpg and you're good.
  
  If you really want speed in browsing the Library (not meaning : waiting for a selection/search to pop up, so just browsing) making the main coverart smaller is a must !
  
  
• New rightclick option "Rename" in the Library Area
  
  This allows for renaming the Album Name in their original locations (!!). Careful : it allows for renaming the underlaying path just the same ! (to your conveniency, but be careful to keep track of what happens).
  
  In order to let this work, a first attempt needs the "virtual extensions" like "(WAV)", "(FLAC)" to be removed, which will happen automatically, but needs a first attempt because of the way everything has been setup. Now, because the renaming also can take place as you're used from Explorer (click, and click another time) - when you do this as the first (instead of choosing the Rename option) a warning message appears telling you to just have another attempt (the virtual extension has been removed now). Looks a bit awkward, but won't go otherwise because of the technical setup and which can't be changed.
  
  After Renaming, you may want the virtual extensions back, and therefore is the new rightlick option "Restore Virtual Extensions".
  Note : When the Renaming is done from a really large set of albums (think of 10000), it may take a while before you can have a next go (or do something else) because the whole list has to be rebuilt for this to work properly. It is assumed though, that nobody has that many albums in one physical location (the one disk won't hold them to start with), and again : this is about original locations only. Apply this to a Gallery item, and the result will be, well, untested at least.
  
  
• New richtlick option Delete in the Gallery Area
  
  Meant to physically remove albums and their related folders.
  Please notice that "and their related folders" is subject to how you organized those folders in the first place. Therefore it is good to check whether your structure can cope with this functionality, and whether it indeed deletes the whole album.
  Chances that too much is deleted are near zero, but -for example- a multi volume album can be organized so that only the individual volume is found (this will be the Gallery Item you click in the first place), while above that a main folder (incl. Coverart) is held, that folder not being deleted. Note though that although this is factually wrong, the volume of the multi volume album will be gone anyway, since albums are not triggered (found) by means of folders or anything, but by means of music files in them.
  
  
• Shortcuts voor Volume Change now always in "small steps"
  
  This means : Before, when Alt-U or Alt-D was used, the volume steps taken were those to be judged "legit". Thus, a 16 bit file played on a 16 bit DAC, or a 24 bit file played on any DAC, officially does not allow the 1.5 dB steps, so 6dB steps were taken for that automatically. However, since files in the Playlist can change ofr format unnoticed, you pressing Volume-up from the chair with a remote, may be very surprised when suddenly the volume changes 6dB, playing somewhat loud already.
  So, not good, but better for the heart.
  In a next version the Wallpaper may indicate "not legit" chosen volumes.
  
  
• Changed remote commands (shortcuts)
  
  Alt-V : Previous Track. Before this was Alt-R.
  Alt-I : Invert. Before this was Alt-V.
  Alt-R : Explorer. Before was Alt-Y (Attended only, and is about the former Library Button, now the Explorer button).
  
  Show/Hide Icons has been discontinued for Remote Commands.
  
  
• New separate choice for using the Wallpaper at Attended
  
  See Settings Area CoverArt - At Attended. When unticked, now no Coverart Wallpaper will show at Attended Playback.
  
  
  
• More intuitive hide/show Icons
  
  Although some small anomalies (occasional flashing) still exist, the hiding and showing of the Desktop Icons now works "better" than before. If you really encounter problems with this, please report.
  
  
• The time bar in XXHighEnd now shows a tooltip how far the track has proceeded.
  
  Convenient for testing. Notice that the tooltip is not actualized when it's visible; remove the mouse pointer and position it over the time bar again, does.
  
  
• Dragging tracks (files) from somewhere else into the Playlist Area, therewith positioning the track somewhere in the middle, again works.
  
  IOW, at some version this stopped working and tracks could only be added at the bottom. Now it works as intended again.
  
  
• It now is allowed to define root folders higherup than before.
  
  Hard to explain, but in short more is allowed now while at the same time provisions are there not to do it wrong afterall.
  Not important for existing users, and not important for new users; Some restrictions just were removed to the conveniency of new users.
  
  
• Support for CoverArt for multi volume albums has been worked out as always intended.
  
  Meaning : Coverart can be positioned at the one higher up folder containing the album name (the folders under that containing the individual volumes with track data), and even a separate coverart folder may be defined there.
  Nothing to explain really, but merely to let all work more intuively hence independend on how things are defined.
  
  Important : While this works out the way as described, similarly it should work work copying data, physicaly or to Libraries. This has *not* been worked out yet (meaning : a dedicated Coverart folder at the level as described may not be found when copying albums).
  
  
• Memory errors because of CoverArt anomalies have been eliminated.
  
  
• When Playback is initiated for Unattended, the tracks being processed are now visible
  
  When no selection has been made in the Playlist (Area) this means that a processed track is being highlighted, and for a selection (which is highlighted to start with) this means that a processed track is un-highlighted.
  Small issue : for the very first track this doesn't count, and it may look the other way around.
  
  
• Playing a selection (Unattendedly) - stop in the middle and continue without selection caused the selection to persist
  
  This is properly reset now, when needed.
  
  
• Time cursor resets to 0 when starting Unattended
  
  This has been in there forever and really served no cause. So, eliminated (hence solved).
  
  
• FLAC tracks without track numbers could cause an error
  
  This happened where no track number data could be found anywhere, and the tag data in the FLAC file was used to work it out as a last resort. Solved.
  Notice that some intelligence has been applied now to workout the track number as a 2 digit number (self srrounded by - and - like -01-), and when not possible, the track number format is rejected hence not applied. Example : 03/25 is transformed to -03-
  
  

Please note : Since so many things have changed, I can only hope that the "install" doesn't lack any modules in the first place. So indeed, didn't test this. If it doesn't work at all, sorry, but let it know.