Well it seems I have solved the problem by limiting the number of characters of each flac file name to 3 (before the 5 characters ".flac").

Before doing this the xxengine would fall over several times per listening session, whereas after reducing the length of the names it has been working flawlessly.

This is a little baffling as I ensured the OS had the disable8dot3 setting at 0 before even installing XXHighEnd and I also tried deleting all the music and copying it back in several times without success.

So I can only think there is something strange about Windows 7 Starter that has caused this. The only other thing I can think of is that as a classical listener, many tracks have the same name, so I have to put them in different folders (I have a seperate folder for each piece of music within my main Music folder and within each of those folders there is a flac file for each movement within that piece).

Anyway, hopefully I have solved the problem and it won't reappear. It is also strange it only began as soon as I started using flac instead of wav. Well, that is one big advantage of XXHighEnd - I cannot hear the difference between flac and wav, and I cannot say that for any other player out there.

So doubling the precious capacity of my solid state drive is a small price to pay if I have to ecomomise with the length of the file names.

OK, thanks Peter. Is there a "safe" substitute for my underscores? For example, a dash ("-"), or is it better to purely stick with alphanumerics only?

I am suspecting it might have something to do with the naming of the tracks. The tracks were actually 11 pairs (so 22 in all as mentioned). Each track in the pair had identical names except for the last character only, which is a 1 or a 2. For example one pair might have been called "ibert_escales_paray_type_1.flac" and "ibert_escales_paray_type_2.flac" (the difference between type 1 and 2 was just the dithering algorythm I used to create the 16 bit files).

So I am going to make the names completely different and see if I can duplicate the error over the next few days. I do actually recall getting some odd error messages back when I first tried XXHighEnd. Back then I was using some really long names for testing purposes (like 20 plus characters).

Anyway, I will try to make the names dis-similar and see if the errors crop up again.

Also, just to answer your other question, sadly this is one of those problems I cannot reproduce 100% of the time. I have tried to get it to crash on those same files and it isn't at the moment (but I have not changed the playlist since remving it completely from the playlist window and refreshing it again. The original WAV files were ones created by me using Reaper (transcription from analogue vinyl LP). They are 24 bit, 48 KHz and I used Sound Forge Pro to create the 16 bit files, 48 KHz files. I then use dbpoweramp to create the corresponding 16 bit, 48 KHz FLAC files.

XXHighEnd began crashing today with the following error:

Problem Event Name:   APPCRASH
  Application Name:   XXEngine3.exe
  Application Version:   0.0.0.0
  Application Timestamp:   4e8c9903
  Fault Module Name:   CliSecureRT.dll
  Fault Module Version:   5.2.0.0
  Fault Module Timestamp:   4bed4d06
  Exception Code:   c0000005
  Exception Offset:   00001296
  OS Version:   6.1.7601.2.1.0.768.11
  Locale ID:   3081
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

This happened several times upon the completing the playback of some (but not all) tracks today. I have not changed the setup of XXhighEnd for at least a week and it has been working without crashing for several hours every day - up until today.

The only changes to the playback computer today were the addition of around 22 new FLAC files into my playlist (which I encoded directly from WAv files using DBpoweramp).

I am a bit stumped here as to what the problem is. I checked the internet for other similar error reports and in the few cases I found where such errors were reported, the developers of the software that crashed asked the users to update their software to the latest version (which apparently solved the problem).

Obviously I am using the latest version of XXHighEnd. I have had XXHighEnd crash a few times in the past but wasn't worried as I was still setting it up. But it seems strange to work fine and then I get these errors as soon as I introduce a large number of additional FLAC files to the playlist.

Peter, can you please clarify something about how XXhigh "grabs" this continguous memory please? I have noticed that if I play a few small tracks (i.e less than 6 minutes each per track) after a reboot, I will get the SFS memory warning message quite quickly - i.e after only playing a few tracks. And this happens to me even if I have the SFS set to a very low number like 20.

But if I play one very large track after a reboot (i.e a 30 minute track), it seems that I am immune from the SFS warning message, even after playing back a large number of files over a period of hours. And I don't need to play this large track right through - I just need to hit the play key, wait for it to start playing and then stop it.

It is almost as if I need to "grab" that full SFS amount right upfront to avoid these SFS memory errors and that the only sure way to do this is to play a sufficiently large track immediately after rebooting. Playing a small track after rebooting seems to cause problems with SFS warning messages appearing quite quickly, but thus far I have not seen them so long as I hit the play button on a track at least as large as my SFS setting after a reboot.

Doesn't XXHighEnd grab all of the SFS contiguous memory as soon as you play any sized track after a reboot, or does it only do this if the track is equal to or larger than the SFS in size?

Hi Peter,

Well I have actually worked out how to enable the contiguous memory options in Windows 7 Starter 32 bit, so anyone who buys a new netbook wanting to use XXHighEnd should be able to use the Mixed Contiguous option (the Contiguous option is a no-go for Windows Starter netbooks due to the 2GB memory limitation - if you try it XXHighEnd will likely just fall over).

Anyway, here is how I did it:

1. Download the Windows Server 2003Resource Kit tools and install it as per the instructions:

http://www.microsoft.com/en-us/download/details.aspx?id=17657

2. From the folder in which the above resource kit was installed, you need to access the file called "ntrights.exe". In my particular case (I installed the kit on my desktop running Home Premium), it was located in the C:\Program Files (x86)\Windows Resource Kits\Tools folder. Copy this file to another folder and you can then un-install the resource kit if you no longer need it for anything else.

3. You will need the "ntrights.exe" file in order to run a command on it using the command prompt in Windows 7 Starter, so in my case I just copied "ntrights.exe" onto a USB thumb drive and took it over to the netbook (but obviously if you have downloaded the file on the computer you need to "fix" then you just need to know where it is located so you can run the command.

4. Make sure you run the command prompt as Administrator. Run the command prompt and navigate to the folder where "ntrights.exe" is installed.

5. Input the following command, substituting "Jonathan" for whatever the Administrator username is that requires the lock page rights:

ntrights -u jonathan +r SeLockMemoryPrivilege

(note, if the username has spaces then the username needs to be enclosed in quotes).

6. Upon completion of the above command there should be a message saying that the privilege was successfully implemented.

7. Reboot.

8. Run XXHighEnd and change the memory allocation to Mixed Contiguous, selecting a conservative setting to begin with - say 10MB (in my 2GB netbook, 40MB seems to be the practical maximum, whereas 150MB worked fine with the Mixed option).

That should do it. After implementing this there should be a very noticeable improvement in the precision and clarity of the sound over the Mixed option.

OK, no worries, it's just that I have found memory configurations (and even the brand of memory modules) to make quite significant differences in sound quality.

Is there going to be any difference in version 9z-7 when it comes out as regards memory configuration or is unchanged since the current version 6-1?

Hi Peter,

I had already read that thread earlier tonight but it was not any help to me. I don't have any of those options available in either of my Windows installs (HP 64 bit and 32 bit Starter).

How do I select the contiguous or mixed contiguous memory options in Windows 64 bit Home Premium and Windows 32 bit Starter?

Neither OS has the group policy options I have seen mentioned and all I get is a message telling me that the privileges have been set and to reboot. But I reboot and get the same message over and over again.

I would like to compare very small cotiguous or mixed contiguous settings to larger mixed settings but I cannot set them in the first place in order to compare.

And yes, I spent a good part of the evening reading SFS threads here but di dnot find any useful information.

Hi Peter,

Unless you can find an obvious or easy to fix bug causing my problem then I would just say forget about it. It seems most likely that it is some wierd characteristic of my Chord DAC and that it would take an enormous amount of both yours and my time (in scenario testing) to try and resolve it.

Tonight I have been approaching the problem from another tack and have found a combination of settings that provide comparable sonic results in adaptive mode - to the point where I am happy to trade off adaptive mode for being able to play any length files in unattended mode without problems.

I could see the 8 minute 41 second limitation being a real pain in the long term, forcing me to be "hands on" with the computer far more than I want to be...and the popular music I listen to would be a real nightmare with that length restriction.

Thanks anyway, but I think this issue is one destined to live in the Twilight Zone.

OK, just tried it without garbage collection on and it made no difference. Then I tried it without garbage collection on and with an SFS of 2 and that was far worse again. It only played the first few seconds of the file before I got the End of Track error message.

As mentioned previously normal mode has the same problem as Special mode. Only Adaptive mode works but the sound quality is signiticantly inferior and not worth the trade off (sonics versus being able to play multiple files shorter than 8 minutes 41 seconds).

I did play around extensivbely with the buffer settings and Q1 settings yesterday (I spent several hours just on that) without success, so I don't think there is any value attempting that again.

I have not tried the garbage collection SFS 2 thing yet. I will try that now.

The DAC does not have a proprietary driver and I am just using the standard Microsoft one (i.e "USB Audio DAC" under Device Manager).

Log is attached. Playlist has three files, namely test_1.wav, test_2.wav, test_3.wav (in that order), each around 25 seconds in length at 16 bit, 48 khz.

End of Track message appears upon completion of test_1.wav at which point I have to bring up the GUI as it will no longer continue playing the other two.

Hi Peter,

My DAC is strictly a 16 bit DAC which is limited to 48 Khz. The only possible settings are 16 bit/44.1 Khz and 16 bit/48 khz. It does not handle 24 bits and it does not handle any sample rate exceeding 48 Khz. Therefore the oversampling options, filtering options etc in XXHighEnd are unavailable and I cannot test them for you or offer any insight into this part of the question.

The DAC is configured in XXHighEnd as a 16 bit, 48 Khz DAC.

I decided to test 16 bit/44.1 Khz and found that in this case, the minimum length file required is 9 minutes 28 seconds in order to avoid "End of Track" errors. Any file shorter in length than this reproduces the "End of Track" error.

As you would be well aware, a 16 bit, 44.1 Khz file with a length of 9 minutes 28 seconds is the same size as a 16 bit, 48 Khz file with a length of 8 minutes 41 seconds.

I also attempted to test the internal soundcard in the HP netbook, however upon testing I found that no Kernel Streaming options were available (only the WASAPI options). Accordingly, it was not possible to explicitly test Special (or Normal) modes. Given that the problem I have described in this thread is specific to Kernel Streaming Special and Normal modes, obviously I could not conduct any meaningful testing in this instance (apart from comfirming there are no problems with WASAPI mode but I already knew that with my external DAC).

Hi Peter,

Yes, I spent many hours creating test files - hundreds of them of all different length timings. They each consisted of an ascending sine wave (in frequency) at -60dBFS so I could just listen in ocassionally to check they were working without assaulting my ears. In the end, if they worked properly then there were no error messages and at the end of the batches of 4, the GUI would reappear without any error messages. Obviously it took me longer to zero in on the exact 8 minutes 41 seconds, since I had to test 8 minutes 40, 8 minutes 45, 44, 43, 42, etc.

There are no concerns about slow playback or pitch issues. I am cursed with perfect pitch (I used to be a violinist) so I can easily tell if the music is not at the correct pitch.

The testing was done exclusively at 16/48. Given I have already spent about 10 hours on it solid I don't really feel like repeating it all at 16/44.1 since I will never ever be listening to any files at that resolution on this particular setup - it will always be 16/48 one way or the other, since the music will be either my vinyl transcriptions converted to 16/48 or high resolution downloads that I convert to 16/48.

I still have not tested the onboard sound with this - I intend to though, if only to know if it is the DAC or not.