Me ...

Thank you for noticing this Russ. I already was that far that it couldn't be coincidence because I never heard it before, but of course it's such a small "tick" (inconsistently present indeed) that it's easy to think it belongs to things. Could be from an LP ...

I will find it ...

It is strongly advised to not use your system without a preamp (or the pre-amp at max volume for that matter) if you or your speakers won't be able to handle a situation that e.g. the file contains wrongly formatted data or otherwise - because of which cracks may emerge with an energy beyond imagination.

The following changes have been applied (all Engine #3, apart from the one time otherwise indicated ).

• Again the calculation of the track length has been changed.
  It was found that ripping programs like DBPowerAmp add informative data at the end of the track, which was not anticipated upon before. Once this data was played as music, it was heard as a "plop". This has been solved now.
  
  
• In the before version the (checked) Mem checkbox was not applied to 24 bit files. Now it is.
  Note that the Mem checkbox still does not (and will not !) anticipate on every situation requiering more memory because of pre-processing, but the worse cases for obtaining additional memory do.
  Keep in mind : the Mem checkbox UNchecked should produce the best sound quality (and uses more memory).
  
  
• As it appeared normal 44.1/16 bit files - not Doubled/Quad/Upsampled - could just be be subject to pre-processing as well in the case of the DAC having more than 16 bits. This has been applied now.
  
  
• It is fair to say that padding to 24 bits is not supported anymore, meaning that 50% of the code does not anticipate on it anymore. So far no soundcards/DACs have been found needing that.
  
  
• The fully pre-processed data as well as the data just not needing processing at all (example of the latter : 44.1/16 which is output as 44.1/16 hence no Double etc.) has been changed for SQ. .
  One thing I will tell you : it enabled my bass volume to be back to normal again (which needed some 8dB attenuation since 0.9t), and XX got rid of the more fumbling bass since 0.9t.
  Anyway, if all is right, apart from the bass you will perceive the SQ change within the second.
  
  
• This version is prone to require more from the OS, and therefore may show crackling at settings (Q1, Prios, Core Appointment) where you didn't have it before.
  Please take good notice of Vista shutting down services, and try to get the grasp of when this happens (usually shown by a message and the spooler system often being the first); you should not leave that message be, but click it away. If you let it be, then crackling almost sure will start to emerge, and it will get worse and worse. When you want to do it right, click away the message, and Stop/Start playback. Usually this is not necessary, but you have to get the hang of things a bit.
  Try to think of Vista needing some settling time for her new situation (without the shut down service).
  
  
• Small Milestone : Some code has been incorporated for Engine #4, and the first sound was heard from it.
  
  

No, of course not Dave. That would be stupid. It all can be solved and it's just a matter of time, priority and some air.
And it is not so easy. That's all.

Wow, you have been busy ...

Let's start with the end : No, everything is 100% from memory, and it always was (each Engine). You may not have expected it, but the "real time processing", is still processing things from memory only. Of course you are not used to it, but since you play without the RAM disk now, look at the disk light ...
There is no single way "playing" from the RAM disk can make a difference. BUT : As you know many other influences play a role, like the spinning disk (or not) and probably the part of memory which is used. So indirectly you can be right (no, will be right because you say you hear it), but this is unrelated to the "playing" as such from the RAM disk. You might just as well fake the lot by copying another album to the RAM disk than you play from e.g. a memory stick (which may sound different again because of using the memory stick).

The list looks normal to me, yes. On the first couple of tracks and mem useage, keep in mind that physically freeing memory is out of anyone's control in the .NET environment, and that the OS decides when to free the memory. At your 1.3GB it apparently thought "this is enough", and that will have happened at the stage of loading the 6th track. Note that this track temporarily needs more than just that track, like the 30MB it would be on disk, needing 30MB for the file + another 30MB + whatever it took for "processing"  after which the first 30MB gets deleted. This takes a few tenths of a sec only, and you won't have noticed it. Of course if the OS doen't throw it away physically, it would add up (like with the first tracks).

I too have 2GB, and it is enough for normal "operation". Indeed Vista takes some 400MB at least, which can easily grow to 800MB "permanently" for the boot session (in my case anyway).


So far these kind of things have bugged me always, and with all Engines (which are all so totally different that there can't be a relation). Everybody will have this. BUT :

Is it a coincidence that you mention this for the first time ? I think not. Why ? well, expecially because the only reason I could find throughout time is that this is hdd related. For me it always has been so that "something" happens within the first couple of tracks, which does not happen anymore lateron. And mind you, I'm talking some 500 days = times by now. It's standard. To me it looks like the hdd spins down rather "hard" (and earlier than should) after a first wakeup - after a longer sleep. I don't know.


This is something you can get experienced on (judging it to the real merits) once you first have the "trust" that it's not the program doing it (and I obviously can have that trust). Over time I learned that this is very easy to "see" once you watch the behaviour of the OS closely. An easy one is the OS shutting down a service, which most often goes along with a message saying so. Leave that message be, and you'll get crackling. But now what, when there is no message ? In my case, most often buttons change (and back), but you already have the W3.11 buttons, and they won't change back.
I know, this sounds a little like voodoo (especially to newbies here), but I really can see it coming. But man, there is MUCH more to this;

I am as far that I can "see" on this (behaviour of the OS) how accurate playback is (if accuracy on this matter may emerge from sending out the bytes software wise). Now first look at your own case : you changed from playing (!) from RAM disk to normal hdd and your OS starts to behave differently. Mind you, this can be impeeded by the prio settings (and IMO it should). So, where normally nothing bugged you (or set your settings so it did not), now it suddenly does. Look at the difference between playing 44.1 and 96, where the latter requires more. It may well happen that at the moment you switch to 96, the OS shuts down a few services (I know, not in your case where you already did that yourself).
My case from yesterday : I changed something again, with the objective of better sound. Well, apart from that I was crying over stupid Billy Cobham tracks (so yea, it worked), all kind of strangenesses happened throughout the hours of playing. One of the most important : the reading / processing of a next track stalled playback during that time (0.5 - 1 sec). What I think with this : the playback is now so much persistent (and looking at the software I can "see" that), that it destroys proper time slicing and once the "reading" thread becomes alive, it won't give away until finished.
And the only thing I did was changing the code a little, and really nothing explicit (but on purpose, which is something else).

Is all of the above the answer to your crackling ? Yes. Apparently you never noticed it, but you changed the means of playback and now things don't workout anymore. Btw, I think 50% of people experienced the crackling, which they in 95% of cases attacked by the wrong means (like changing Q1, Priorities). I say it's only a matter of let the OS settle with the services, some means to enforce that, and looking at it in a way actually nobody can. So it's not easy.
For me though, it is 100% sure that once you did not have crackles, but it starts, you just have to wait until things settle. This *always* goes along with Stop/Start, because once it happens, it won't go away by itself (and the waiting is a matter of seconds).


So this is what I was just telling about myself. I never had that before though, and you don't have that software version. There are just more ways leading to Rome (well, away from it, this case).

IMHHHO useless.
Ok, for installing the OS (and swap file) on it.
And *then* it is up to me to shut down the hdd the music came from.

If it not already was, then it will be ...

I just found the comment as shown below, which makes my last post not being the truth either.

What it now comes down to is that this part of the pre-processing code has to be split into half-pre-processing (as how it was before) and full pre-processing (as how it currently unconditionally is).

Oh well ...

Oops. Missed that phrase.

Ok, I just looked, and things appear to be a little different ...

a.
There *is* old (and new) code for 24 bit files. Indeed the old code pre-processed already, but very minor stuff still had to be done in real time (coming down to expanding the bits). This has been changed into "all pre-processed" with the penalty of additional memory useage. Can this be worth it ? probably not.

b.
Since I apparently forgot about this myself (see previous post ) I *also* forget to let this be subjective to the Mem checkbox.
So you are just 100% correct. Again ...





PS: I only now understand that the dedicated topic as originally created by you was just justified. So I put it back in its own topic.

Hi Mani,

If all is right, this is related to your own remarks about 96/24 being preprocessed (IIRC it was about just this), which never has been different. So, no "old code" exists for this ... (hence the Mem box can't change anything to that).

Of course this is inconsistent with my own remarks about it in the Release Notes ...
Peter

Ok. Offline this has been worked out with Edward;
As it turned out, rips can exist with informative data at the end of the track. Anyway DBPowerAmp does this. If this is not anticipated upon, obviously this gives a "plop".

It has been solved now (in 09.u-8), and all was held against other problem tracks known from before.

Oh, I forgot. When Double is in order, multiply the expanded part by two. Mentioned "three times" is now five ...
Do I need to explain about Quad ? 


I know it's crazy.

Maybe you can understand it a bit if I explain it like this :

a. The file is read into memory;
b. From memory it needs expanding to 32 bits. For 44.1/16 that's now three times the data;
c. For gapless the next file needs to be read into memory. Note : a. is deleted by this time. This is still three times now.
d. b. repeats. That totals to 5 times.

With 24 bit files it's a little different (1/3 is added) but the files are bigger to begin with.
With 96KHz files all is again bigger to begin with.

Roughly you can say that 3.5GB is needed now for two subsequent tracks that comprise of a full CD. It's slready hard to find even one of those (but they do exist, like Amarok from Mike Oldfield), so it's all not that bad. Also, for the exceptional situation of subsequent tracks being large (and two 20 minute tracks would be that) the Mem checkbox is there.

But cutting down the memory to 1GB ....
You should have 2GB available, as the "specs" say. And yes, officially the specs should change now (with the additional preprocessing), but I'd rather use the Mem checkbox. Also keep in mind that not all 32 bit OSes will recognize over 2GB of memory (AFAIK).

So ...

Well, so virtually you are using 1GB. That can't work ...
FYI, when I run things in the Double/Preprocessed mode, I have a rather constant just over 1GB of memory in use (including Vista and all). This does NOT accumulate. It does for the first few tracks though, and how is too difficult to explain.
Maximum I saw was 1.7GB with a 23 minute track, BUT, this was preceeded and followed by "normal" 6 minute etc. tracks. Two subsequent tracks of 23 minutes 100% sure wouldn't have fit.

So again, if you say it accumulates (btw implying a "memory leak"), please prove that. But better don't, because first you must have enough memory to prove it, and 1GB is not that.

About our discussion long ago : the RAM disk IMHO does nothing more than disturb you, *unless* it can cause all the disks to spin down. So when the latter is in order, I'll say nothing. But if the disks keep on spinning anyway, you are just adding another layer of memory, and you shouldn't. Keep in mind that XX already plays from memory 100%.

And I know, I once promised to look into spinning down the disks myself, of which I'm sure it can be done but not in in easy way (I looked into that some time ago).

Ok ?

But wait a minute ... You aren't telling you are using 1GB of memory only ? or ?

Are you sure it keeps on accumulating ? I mean, you shouldn't look at just 2 subsequent tracks, but just "all" of them. Also, it's more complex than just two tracks being in memory at a given time, but never mind that, as long as you don't calculate wrongly.

If you have tracks of, say, 100 MB each, you can run them forever. But if you can prove it cannot, please say so.
Here it's no problem ...

Edward, I want to ask you please ...

AFAIK you are the only one reporting such a thing. BUT, if others have it too, please say so !!

At least I never experienced it. Also, I don't know what to do about it. What it comes down to is this :

When you don't experience the pops, I appreciate the file length in the header. But, I actually can't because it is so often plain wrong. Mind you, up to a number of bytes which can't be divided by 4 (or 6 for a 24 bit file), and if I don't deal with that properly you'll be in big trouble (cracking windows etc.). Now :

Since I can't think of why it would be wrong to respect the physical file size (offset by the header data which I *can* find properly), it must come down to "something" at the end of the track which your soundcard (DAC) can't deal with. As I said before (elsewhere ?) I expect that to be zeroes, just because I have seen it in files. Now :

Could you by any means (I can't think of which) verify that it is just XX not being able to cope with it ? Btw, XX = Vista Exclusive Mode which obvioudly gives way more troubles than anything else. On this matter "anything else" is kernel code which somehow deals with it, while in this case I have to do everything myself. But I don't know how ...

If you have the ability to check with another sound device, please do.
If you find "anything else" to cope with it, please check whether that plays gapless. I mean, I too could cut of  a couple of 100 bytes in order to avoid the problem area, but it would be a "standard" solution then (playing not gapless for that couple of 100 bytes which is *hard* to detect because it would be about less than 1/10 of a second).

I don't want you to spend hours on this, but if you have any easy means to check, please do ...
If I'm not clear, please ask.

Thanks once more,
Peter