I guess not. But if so, you can try 0.9w-2 (as how it is today) and see whether it works out for you.
Note that the solution is based on the presence of a .cue file, and not on the (header) contents of a FLAC file. It would not be a common way to do it like that at all (if possible, which I did not examine).

Please let me know,
Peter

I finally understood this question, since I took some time to rip again lately (which I hadn't done for years).
Yeah, this didn't work comfortable, or actually there was no provision.
Strangely enough the "let XX Rip" solution slipped through my mind as well, but although you're more integrated then, you'd still need something lik I now created in 0.9w-2. Here's an excerpt from the release notes of that version :

---

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.

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.

---

I hope this is a good start off. Ripping will be in there too, just because I think it can be faster *and* better.

Certainly not, meaning : the only difference you will notice once you use the "proper" (zee below) cpu is at conversions which are very cpu bound, and the faster the cpu the earlier they are behind you. But also read the Release Notes on 0.9w-2 on this matter, because it might free you from clicks and such once the cpu is faster. This goes way beyon the few lines spent in there, but it comes to this.
On the other hand, my Core2Duo is 2.4GHz only, and if one never has problems, it's me. But that's me ...
With the latter I mean, once you kind of know what you're doing, you will be able to avoid problems. When ot or less, you can buy them off with, well, money. Mind you, in general. But many many things are speed incurred, and the sooner the problem is over, the less you will notice it, or even - occur.

Personally I wouldn't bother (at all) for higher clock speeds and the necessity for more cooling, as long as you don't over clock. Again, leaving off the lid already solves all, although it may be a strange solution (and sight of course). When leaving the lid on, it is just (and only that) of the utmost importance that you keep the PC (hence motherboards, PSU inlets, CPU cooling lid) clean of dust. This is just a matter of blowing through it with a compressor which every car repair as and will be glad to use (on you). It is too less realized that this does most of the job, while at the same time it *is* realized that when the PC was new it was so quiet ...

In any case, do not give way to the cheaper cpu's like Celeron, because they *will* matter on sound and everything else. And as a major rule : the 2L cache is what heals all. The more you have of it, the exponentially better things work out.

Hope this helps a bit.
Peter


PS: A nicely water cooled system looks way "cool" of course. Must admit that ...
PPS: Do not make the mistake that XX needs the clock cycles. It is the other (environmental) processes which do and which can disturb. Like a disk, a cpu can trash too (for sure a multi core -> dying from overhead at switching shared memory). This is the first thing to avoid. But hey, back in my old days I claimed to better have a 12MHz than an 8 MHz cpu. Now what.

---

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.

---

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.

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

Generally, yes. But of more importance is the size of the fan (a tad larger makes a huge difference in neededs revs) or just water cooling.
Without notice, there are fans for the case (could be two), the cpu and the PSU. When the cpu is not stressed, they run on the lowest rev. However, since all is pro-active (what is the current temp ?) the smaller the fans, the more they have to work to make the needed flow.

Just some strange advise : nowadays, as it turns out, just leaving the case open (leave off the lid) just makes the difference needed; It is quite impossible to incur for a higher environmental temperature, impeeded by cpu or hard disks. Just my own experience.

Peter

Hey Johan,

It seems hard to imagine i.e. I can't think of anything that would cause it.
It could be coincidence because (somehow) your system may get slower and slower for harddisk I/O's which is reset when playback is stopped (???). But then you must be able to see that because of the hdd light flashing longer and longer.

When you can see hidden files :
In your XX folder there's always an XXDat0001.das file when you're playing. When this happens again, could you send me that file ?
Note that at each next track it changes, so you could send me a couple of them (when a track started playing, copy it to a unique name, and do that for 3 or 4 tracks).
I'm almost sure it will only show the opposite (hence it is not explicitly controlled like that, which *could* happen), but then that option is out of the way anyway.

Thanks,
Peter


PS: I must admit that I sometimes think the same, but not after a longer period of playing. I did find a missing sample indeed. Hahahaha (solved in the upcoming version btw).

I just realized that the log shows how many times XX is started because each new session creates a new log file.
I am at 260 today. So far ...

Didn't even hear one single note of music. What a life.

Well, don't change your DAC because of this !

I unerstand your confusion;
When gapless is required (and we just have to state it is) there is a small overlap near the end of a track when the next track is loaded.
This is unrelated to starting playback during conversion (!!) of the other tracks right after the first track has completed conversion.

So, "conversion" happens in advance of everything, however, during that stage again the harddisk is used (excessively), and after that has been done, there is still the loading of the tracks from harddisk (during the end of the track playing) which doesn't need conversion anymore then. It is that stage (and at conversion when in order at the beginning) that the USB bus has priority over the data that has to be supplied to the DAC. This is when you may receive hiccups, ticks and glitches. May ... because when everyting is fast enough or happens at convenient times, nothing is the matter. This is related though to the Q1 settings, and you won't be able to set that as low as you may want for the best SQ.

Besides all (and this may be of importance) when you have some mass copies going over everyting but USB during playback, I kinfod guarantee you will never hear that to the sense of hiccups etc. But when you have even one going over USB I dare to guarantee that you will notice.
YMMV but this is just how the theory is. Also, I don't want to be right on this, but instead I just want to warn you. So just keep in mind : there is no way playback can be interrupted (Engine#3), unless you incur for stuff which has a higher priority which nothing can be done about. USB is one reason, challenging the swap file is another. I don't know of any other currently.

Hope this helps ,
Peter

I guess the motherboard isn't that important when you don't have requirements on SataII connections (which as SeVeReD's base). The Core2Duo (mind the difference with a DuoCore !!) is the main requirement and the more Level2 cache it has on board, the better it is.

When the unit is not connected to the Internet, a USB stick suffices. Just download the update to the stick, stuff it into the audio PC and unzip it from there (or unzip first at the receiving PC, doesn't matter). Then copy the contents from the stick to whereever you intended as usual.

BUT :
The main mistake you make is having USB harddisks and a USB DAC at the same time. Besides USB is relatively (very) slow, harddisk acces has priority over the data going to the DAC. It depends a bit on what you do and when, but for sure it is asking for (playback) troubles.
When you use similar now, it is *not* said at all, that this will prevent you from the problems as implied on the new machine ...

Peter

That they have a shortcut at all is a pure coincidence. I never payed attention to it, and the double P probably came from copying one to the other.
Since it is about time now (meaning this weekend) to start the remote control stuff, I will be solving it for that reason already.

In the mean time, if someone has ideas about what shortcut should be applied to what button (e.g. because it is a standard for players -> I just never looked into it (yet)), please step forward.

Btw, keep in mind (although I'm not sure why yet) that we will be remotely controlling a player which actually isn't there in the case of Unattended Playback. Another challenge ...

Hey, I didn't know that ! This is great ...

Thanks Andrey.

200% agreed. Sadly I started off in dutch, and I don't think there is a way to upgrade to english.
Reinstal from the beginning would take me x days of installing the development environment, which is just necessary here.
But again, 200% agreed.

I sent you a private message ...
Peter

Andrey, great thanks on behalf of everyone who is going to benefit from this !
Peter