Well Russ, do not hesitate to blame me for having sleep in my eyes, but in your latest post I seem to read everything the exact other way around of what you seemed to want per the first post, while the latter seems logic to me (hence your last post not at all) ?

It is about date *creation*, right ? (btw, it just is, and obviously (??) not date modified).
Moving files around to other folders, which may include a renewed creation of the folder the music data is in, just will not help you (the opposite).


Maybe here is your misunderstanding (yep, yours haha) ? First of all, this seems to be a contradiction within itself, and secondly when I rip an album at Sep 19 2008, copying it around won't change that. You seem to imply that you would *want* to change that, which is the most illogical to me. You would want to keep it, ... which it does. No matter where you copy it to.

Most probably you are confused by looking at the DateTimes the system shows (in e.g. Explorer), which btw Vista does a little bit differently from XP. But you should not look at that, and look at the DateTimes XX shows you, instead. They are just the originals ... and as said, even if you FLACed the files in between (or deFLACed for that matter).

Now shoot me ... I'm awake now.


The sorting is half in by now. I suppose you just *will* get that.

Andrey and Russ,

Actually, I have been working on nearly each of those suggestions the other day (the enqueue on the current playlist I didn't think about before, but the idea is as good).

The technical problem I face (and this has been in here over one year ago I think) is that so far XX doesn't have an official install, and thus no file associations, and technically things go wrong at the determination where XX recides, or IOW, where to find the DLL's and all which are expected to be in the "start up folder" ... which will be the folder you're in, selecting that music.

So, this is a technicality (though a bit difficult to overcome) which ... I am trying to overcome right these days.
I think you can be sure to find this all in the very near future, just because I want it myself. Ok, because you want it.
Nah, it just belongs in there.

Peter


PS: Andrey, I know what you are talking about with the slow laptop and the coverart. Even on faster machines it slows down too much to my linkings, if coincidentally an album is actual with larger coverart files (and many of them). Coincidentally it was the next thing on my list to "eliminate" that from startup times. So, *that* will be solved in the next version anyway, if all goes as planned.

Hi there Down Under,

If you look at the first picture below, the mouse pointer points to this little "D". Clicking that brings up the Date Picker.
I selected from Nov. 1 2007 u/i Jan 31 2008;
The second picture shows (a part of) what I ripped in that period. You can see the exact dates and times doing that.
FLACing doesn't change those "rip dates".

So, it is not sorting on that date, but you can select on the period anyway.
I now realize that I could sort on the date/time just the same, but I'm not sure whether that would be a better thing to do, *assuming* you know the period to select. But if you don't (know it exactly) ... hmm ... I guess I'll provide the option to sort on the date/time. Seems nice.
Peter

Always nice to hear those happy sounds Dave.

Re the Cue File business ...
I think I am up to reading the files partially in the first place (whereas currently it's always read in whole, as you know);
I just finished some conveniency features for myself in the program, that will allow me to do this now easily, I hope.


It is not all *that* easy though, which is also related to Cue Files and Ticks for nitwits ?

Allow me to notice something I never realized, and possibly nobody did ...

In order to understand, you should grab that EAC grid that shows the file offsets in bytes and the track times next to it. Now you tell me :

There are 44100 samples in one second, and since one "audio word" for one channel takes 2 bytes, one sample takes 4 bytes, so there are 4 x 44100 = 176400 bytes in one second. Track times are reported (by EAC) with a granularity of .01 (1/100) second.

1 sample takes 1/44100 seconds. We don't need to calculate more to see that the theoretical granularity needed is higher than EAC reports. What I say is this :

It is the data domain (the bytes) that determine where a track ends. This is a random offset in the file, as long as it can be divided by 4 (for 44100 files). Of course the base for my statement that this is "random" emerges from the fact that musicians don't stop playing at 1/100 second boundaries *and* that during the mastering process this isn't mapped onto 1/100 seconds either. The latter I actually don't know, because it might well be that the (software) consoles used work in the time domain, and that cutting and all is presented with a 1/100 second boundary. But hey, there won't be a law in this, so I take it this is *not* the case.

Need I say more ?
A Cue File composer like EAC will be using a(n unintended) virtual rounding of the end/start of tracks at 1/100 second boundaries, whereas it is not said at all that this can be reversed to the actual byte offset. Example :

We have a track that is reported (by EAC) to last 50.01 seonds. That means a byte offset of 8,821,764 bytes (50.01 x 176400).
In reality though, the track lasts e.g. 10 samples more, thus 10 x 4 = 40 bytes more = 8,821,804 bytes.
Now, when this track lasts 50.01 seconds, the next track (think gapless) starts at 50.02 seonds. And keep in mind : there is no better granularity like 50.01350 or whatever seconds. It's 50.01 or 50.02 and nothing in between that. So, the next track will start at 50.02 is byte offset 8,823,528. Uhmm, we missed 8,821,764 - 8,823,528 = 1764 bytes = (/4) 441 samples = (44100/441) = ... 1/100 second.

441 samples is way enough to let jump the voltage from e.g. completely negative to completely positive, whereas the music intended to let that slide by means of 441 steps.

Looking at beforementioned EAC grid again, this indirectly works out (or is worked out) differently : Where the byte offsets do not show a gap of even one (four) byte, the lot including the time domain is represented as :

Track end	8,821,763	Time end	50.01
Track start	8,821,764	Time start	50.01

The above implies that
a. The track ends 10 samples early (see above outlay);
b. The next track starts 10 samples early (no problem for gapless)
c. One sample is repeated.

Where the above example was about 10 samples being off, the maximum will be right in the middle of the 50.01 and 50.02, hence 50.005, or 8,820,882 - 8,821,764 = 882 bytes or (rounded) 220 samples. That is, if EAC rounds and not cuts (which we don't know).

Even when we're 220 samples off, this is never a problem, because when we's start an e.g. 3rd track of a gapless album, who will know that the 220 samples early or late start belog to the wrong track ? ... it just can't (be known);
When it's a non-gapless album, the 220 bytes (0.005 seconds) is way too short to end up in the previous or next track, knowing that the gap is in between 1 and 2 seconds.


Concluded : The only thing being wrong is that with two subsequent tracks playing while the music is gapless, one sample will be repeated without very special attention. This special attention means : start the track one sample later than the start time implies. And, since this would be wrong for the first track, this comes down to end the track one sample early. Too bad for the last track.

At the moment of writing this, I am dead sure that XXHighEnd applies the end at 50.01 and start at 50.02 syndrom, just because this is (was !) the most logical thing to do, and this is how the human being calculates. This means that for Cue Files, currently, 0.01 second will be missing between tracks ...
... which for gapless may incur for a tick because of voltage jumps which should be spread over 441 steps which is now done in 1 step.




PS: This is all *not* related to the tick and small repeat or echo which may be audible in Cue Files in between gapless tracks which shows in all versions u/i 0.9v-6a (and unofficial 0.9v6-b), which was caused by a calculation error in the time domain, which reformed an e.g. 0.09 to 0.90 (implying a very similar error as what this topic is about, although of a 10 times higher magnitude, but which is exactly what brough me to the subject here).

Dave, your problem is one of another kind, related to Cue Files. Something with Index 01 and Index 02 which sometimes exist and a wrong interpretation of that from my side.

Johan, did 0.9-v6b help you ? I'd like to know before putting up another version.

Ah ... ... I only now understand what's actualy happening. You're *playing* ...
Yes, of course. Never thought about that. And if you then see that I was building the log the other day, including the message "Music file found" (you can see it in there), and I was overthinking that maybe there should be an official check for that in the program, because it wasn't there ... *and* I was thinking : nah, that can't go wrong because it was just checked by XXHighEnd ...

Will be solved in the next version Adrian.
Peter

No, I can't get anything to change for the Windows folder either. But then I did not need to in order to get all the things applied from the "tweaked to dead" topic.

Indexing to my c: drive is off for sure.
Ah, but you can wonder whether that succeeds by means of my suggestion : apply to all files or whatever it exactly is. I sure can imagine that this can't be applied to the c: drive because it really physically goes through the files and amends something (I think). And that won't be allowed for the Windows folder ...

To be honest, I can't recall that I did this for the c: drive. I was always more bothered by the data drives, and by pure coincidence my Galleries (which is a million of files) are not on c: but on d: though the same disk. You indeed they could be shut off, and I'm sure I did "those" (hence d:). It took over an hour iirc.

I just wanted to try it for you, but didn't dare to press the button. I mean, my system *is* dead quiet, and it could only get worse. And before being able to shut indexing off the proper way, it has to be turned on, right ? So ...

Btw, my poor Vista still has the 1000 for a standard (something's really wrong there, but aparently it doesn't bother for audio playback).

Could find this for XP only : http://support.microsoft.com/kb/308419/en-us

Maybe it helps somewhere.

I don't know. What I do know, is that when you don't have just all the rights there are, you will run in some problem somewhere (mostly noticeable when doing things over shares / the network.

In the mean time, for Johan at least, I found that the rights for Create folders/Append (see arrow in the picture below) are the most logical rights to prevent you from appending to a file. Not that it makes sense, because the log file acts the same after it has been created explicitly, as was the old way of writing to data files Johan couldn't cope with from the start.
Anyway, I'd suggest to give yourself all the rights there are, which are summed up on the page that shows below (including the second screen copy). Note that this place just shows the "effective rights", and they are to be applied at the higher level form you see below (the "Bewerken" button). Some will inherit though ... from somewhere.

Johan,

I'll bet at least something that withgoing 0.9-6b solves your problem. Why ? because this is officially known as the JohanZ problem and again I had to solve it. Somehow you don't have the rights to IMPLICITLY overwrite files. Explicitly yes, but implicitly no. It would be very nice for me and all others you may address this to without knowing, and in the end for yourself of course, if you could solve this.

I never heard of the thing, but it comes down to this :

Certain commands that create a file have the option to append to it, instead of deleting it first automatically and then create the file and add the data. What is used here is the latter, hence the file should be newly created or at least the contents must be new.
Note (hence disclaimer, whatever) : I don't know whether in such a case physically it may be so that the file keeps on existsing at the place it was before and that somehow its contents can be made empty before the new data goes to it. It certainly looks like this, because this is the explanation on it :

"To truncate a file or create it if it does not exist, use Create".
(truncate means cutoff, afkappen )

It is this "truncate" which doesn't work for you.
Again, I wouldn't know of a "rights" setting that disallows it, but maybe you could look for it, or just allow yourself for everything at least in your XX folders (that's where this happens). Now Johan : actually it is not about this (hence XX) because I solved it. But what about the rest of your PC ??

In this particular case the writing of these files was changed due to the main subject of this topic (Wav stops playing), and I made the mistake of not paying attention to your problem. So you really don't need to do anything for getting XX back to work again. But again : what about the rest of your PC ?

The huge disclaimer is of course : ... all counts only when the below zip helps (only XXHighEnd.exe is in there).

For SeVeReD / Dave : If it helps you too, you can join Johan.
Anyway, let me know what came from it !

Russ,

I actually do not want you to approach it like that;
The 9GB for disk space is obviously no problem. The "load time" as such, is unrelated either !! It just doen't work like you logically will think. You can say it's smarter than normal logic.

But there are other things which incur for a perceived slower "load time", and they are cpu bound and again unrelated to the amount. Trust me.
There are a few things that are - so far - beyond my understandings, never mind I created it myself; I have one source folder consisting of some 1000 albums only, which is hardly manageable when it comes to the response is requires. When this source is incorporated in a general Gallery, that becomes as slow, although it seems to average out with the rest of the contents of that Gallery.

So, there is just something wrong in "some" situation, and I have to find out what it is. I know this for some weeks now, but didn't spend the time on it yet.

It *is* true that a larger picture takes more time, BUT this only works out as a pain when it shows up in the CoverArt Area (rightmost pane);
It *is* true that at Selecting the lot in the middle pane (as you described earlier today) just the same phenomenon causes the lot to be superslow. But this is wrong by itself, and the selection should not show up in the right pane. That's a bug.

So only - and only then - when you click an item in the middle pane, it is "legit" that this is slower because of showing large pictures in the right pane. Do NOT shrink *those* pictures to 500x500 whatever, because logic tells that large pictures are there for readability (like the back of a cover, the inlay, etc.). Shrink those to 500x500 and you won't be able to read it anymore.
And yes, those readable pictures can 6MB or even more. But again, they only bother when you click an item in the middle pane, and when you're in a process that this slows down all the time, untick the Show Coverart box.
So, that this consumes 9GB does NOTHING. Just nothing.

Peter

Oh, I hoped you found that to be a nice slide show ?
Yes Russ, I saw that too (only day before yesterday). That will definitely have changed in the next version.


I do this in order to keep the data disks shut down. So yes, that creates redundancy and a lot of problems for the developer, but I thought it's really  better. Of course you are right that the folder.jpg only would do a rather nice job already, but it is not that simple, because people may call that cover.jpg, front.jpg, tray.jpg and 20 more. So, it would shift the determination from real time to the moment the Gallery is created, and as you can image the software changes here and there (hence better have it real time). Besides that, you'd miss the additional coverart, unless the disks spin up again. Btw, not a real problem for me, but for the waiting for it (I think I have 8 now, and the subsequently spin up, not in parallel. That's 8 times 5-10 seconds ...


So yes, but these are for the maintenance of it all. So, when nothing comes up in between, in the next version this will be used for moving albums to other Galleries, show where an album sits, rename albums (the folder to it), changing these things outside of XX and then "repair", etc. Currently it is used to maintain the consistentlcy with the coverart as mentioned above. E.g. rename img002.jpg to folder.jpg from whichever angle (GalleryA, GalleryB, the orginal) and "redistribute" it (hence cover for the redundancy).

But Russ, please keep on coming up with your ideas in directions like these, because it is really difficult enough without using a database (which I so far tried to avoid).

Peter

You must select the range of albums you want to tick. So, first select those, then order for Select All (checkboxes).
Unselect All works the same, and *that* is not the most convenient; right now, this kind of makes you select - apply (to Gallery) - unselect all. Otherwise you won't get rid of the checkboxes anymore, or you don't know where you were, etc.

I'm working on a vast improvement in this area. Next version ...