Edward, you are just right. I completely forgot about that. Of course I did not expect the pops to be there witht the new code. BUT, the old code now reverted to checking the file length as before *not* having the problem, tells me much.

Thanks for reading better than my own memory is about my writing. I didn't write it for nothing of course.
Now how to solve it ...

It's just program error. Nothing to do but wait.
No better, just switch Crack Detection Off (in your case !).

The old. But note your context in this quote. And see below.


*Here* you'd be using the new code.
And, after three days of consecutive playing I agree with you. For me it took albums like from Emma Chapplin to find out. Actually she should be the first for (me and) everyone to try out. In all cases so far, her voice (and that really is enough to judge) sounds annoying when things are not right.

Btw, the shift to the higher frequencies I can agree with for net effect. What IMO technically happens though, is that dynamics grow excessively high. Just watch closely what you (or your wife) can bear for volume, and note that this is not about "raw" etc. highs. This is something else which can't be measured ...

This is what happens :

1. The Crack Detect does trip on Cornershop, and let's say this is a case of too many too high transients (remember, which officially can be that high, although it is rare;

2. Normally the Crack Detect works per track. In the case of Cue Files though, it works for the whole album. It doesn't matter much really, because the 13750 is way too much to lower the treshhold for tripping (as how I use it), which comes down to 20 "cracks" per track, or in this case (15 tracks) 300 for the whole album.
Of course the detection should work per track, but in the Cue File case this just doesn't work so yet. It will though.

3. We don't know which track is causing it (seen 4 below too). BUT, coincidentally the second track indeed seems to contain "ticks" of a very high transient, and which seem not normal to my ears. On the other hand, it goes along with the rythm of the drums ... but otoh again, I don't think it is a drum machine used there.

4. When you'd drag the timer position cursor towards the end of each track (Attended), you would see that at each track boundary the Crach Detect trips. BUT, it does not at the normal start (press Play) of any of the tracks. Conclusion :
Crack detect just does *not* work on Cue Files. Unintentional of course, but only at track boundaries the code concerned is triggered. I can't think of how at this moment, but apparently it just is so.

Is the latter a bad thing ? officially yes. For you not. As I said earlier, with 16 bit output nothing is changed to the code apart from the Digital Volume, and even that you don't use. Also, since the Cue File Brigade rather officially consists one one man only, nobody has to worry.
Btw, *with* the Digital Volume used, the code isn't triggered at all for Cue Filles. That is, I can't get the Crack Detect to trip then.

Lastly, things seem so strange to me (the combinations) that it even could be that the Crack Detect trips on *me* doing something wrong in the code in that situation (Cue Files at track boundaries, and no Digital Volume). Of course this is the main reason why Crack Detect was built in (me just doing something wrong), and maybe I shouldn't be ignorant for that ...

Again for you, nothing to worry about (UNLESS THOSE THICKS I MENTIONED ARE THE RESULT OF BAD CODE), and *IF* others use Cue Files as well, but with more bits in theirs DACs, then please be careful.

You would be able to use it, and you then can attenuate to -48dB without loosing any bits. Attenuate more and you won't be able to hear the lost bits.


Currently, correct. But of course this is something to solve. It is just that it is not so easy why it wasn't done yet.
Let's say that by the time you have 96/24 running, I will make it for you ASAP. Ok ?


This is another matter;
When individual tracks start to be over 30 minutes or so, it won't fit into memory, especially if the source is 96/24 as well.
You could buy additional memory for that (but be careful your PC sees it which IMO for a 32 bit OS is not always the case), but ... you could also say that for that more rare long tracks you use the Mem checkbox. Also note that you'd first need to judge that checkbox unchecked as better sounding.


If I understand the question ... No. But note that also it just isn't needed.
Also note that even *with* Digital Volume it isn't needed for 16 bit output. That already was pre-processed, and nothing changed to that matter. Only more than 16 bits (output) benefit (if at all, and to your judgement, once you can).

Maybe it doesn't help, but I would put my bets on you forgetting something afterall ?
Why/how would a soundcard be broken ? Of course it can, but still ...

I talked about the pop which I expected the other way around.

But ok, the pop occurs at the end of the first track ?
Or always, in this list ?

And is this not FLAC now ?

I can try ...
But it's strange. If anything I had expected it to be the other way around.

Can you please make a screencopy of your playlist area, and indicate which track is playing (and which is the next to play), the first mentioned ending up in the pop ?

Thanks again.
Peter

Ok. Thanks. I'l try it.

Yeah, I was thinking about that myself. Answer : No.
Question : Does it trip when you check that Mem box ? If not then I'm doing something superfluous ...

But I'll check with that album we share (later).

In fact, this is the most interesting. I think I have that Cornershop album, although I can't be sure it is the same pressing (version).


I don't think so Dave. All is about the "processing" needed to use the Digital Volume and exploiting the larger bit depth (which you can't ).

Btw, I just looked ... is at least your picture of "When I was born" the same ?

This is the result from your Priority settings and Vista not being able to service the -whatever service it is- anymore.
It doesn't harm (as long as you don't want to print something, in this case). The only thing which can happen is that during the moment the message is shown to you the sound starts to crackle (more and more). Just stop and start Playback in that case.
There can be many more services shutting down, and as far as my own experience goes none of them harm the system. You can end up with Windows 3.11 buttons though.

If you care about this (I don't) higher the Priority('s) you lowered.

Btw, the more you urge from the system, the earlier/more it happens (like e.g. 96KHz playback urges more).

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 only, unless otherwise indicated) :

• As the title implies : SQ is changed for bit depths over 16 bits.
  
  What actually happened is that the processing needed in order to apply the higher bit depths (and which for a large part comes down to padding (expanding) to 32 bits) has been moved from doing that in real time to pre-processing code.
  
  In order to get a grasp on where SQ changes can be expected, you can think of any playback means that implies a higher bit depth than 16. Thus, the first prerequisite for that is setting the DAC to 18 bits at least (and of course the DAC must be able to exploit those bits). Then, any means needing "expanding" the bits will trigger the new code with one exception : normal 16 bit playback using the Digital Volume Slider (because this already was implemented from the start with "pre-processing"). This will trigger the new code :
  
  - Upsampling;
  - Double or Quad without Upsampling but with using the Digital Volume;
  - Playback of any file natively having more than 16 bits.
  
  There is one other exception currently not triggering the new code : Cue Files; Because at this moment a Cue File album is processed in full (hence not per track), it will not fit in the so far advised amount of memory (2GB). See the next topic as well.
  Note that when the DAC can't exploit more than 16 bits, this doesn't matter anyway (special message to SeVeReD ).
  
  
• Because the pre-processing requires additional memory, it is expected that tracks covering near a complete album, won't fit into 2GB of memory. This depends though on several other things and combinations;
  
  When it occurs that you are low on memory indeed, you can tick the new checkbox in the left pane that says "Mem", and the old code will be used, using less memory.
  Of course you can use this checkbox just as well for comparing SQ of the both means.
  
  Ticking the checkbox changes the playback means in "real time", but note that changing the state to "pre-processing" will take some while before playback recommences. Btw, all the changes which can be applied in "real time" will take longer when the Mem checkbox is unchecked.
  
  
• The Crack Detect feature can be switched off when needed, with the new checkbox for that in the Settings Area;
  
  Note that Crack Detect trips on unexpected (read : abnormal) high transient responses, but that a track could just contain that. Thus, when a track won't play but you don't expect anything being wrong (see read text above !), you can switch it off and the track will play anyway.
  
  Another reason will be playing formats like DTS, which *will* trigger Crack Detect. Here too, playback can be forced by switching off Crack Detect.
  
  
• The Combox for Playlists now will grow wider when the (invisible !) splitbar is dragged to the right.
  
  Note that all forms around the coverart picture which needs to be near square, and it will need dragging the bottom of the form downwards just as well.
  
  
• As it appeard, 88200/24 playback was not supported. Now it is.
  
  The same accounts for 44100/24 and 48000/24, although these both were not tested.
  
  
• Since 0.9u-4 another means of determining the track lengths better was applied. Now this has been set back to how it was before;
  
  Although it is not sure that it was the cause, "plops" were reported at the end of playing a track. When you wish to check whether all is back to normal, test this with the Mem checkbox checked;
  When this checkbox is unchecked, the means to determine the tracklength are very different again.
  
  
• The Embedded Explorer has gotten rid of its "Album Count" as well as the "Link Indicators" (indicating Library Meta Data instead of physical files);
  
  It occurred that the state of the Embedded Explorer could turn into "an ever wanting to count", therewith making things unnecessary slow, and besides that it was generally more slow anyway. Net this should be better for feellings (of response).
  
  
• The bit rate on the Wallpaper Coverart for WAV files has been restored, and besides that the bitrates now show correct for all file types. This counts for all Engines.
  
  
• In the Info Area the bit rate has been added. This counts for all Engines.
  
  
• The response on stopping Playback has been worse since 0.9u-5. This has now been restored to normal.
  
  

Expectation on SQ changes for normal 44100/16 playback (UnAttended) : nill.
SQ changes for most of the other playback means : Yes. Please let know what you think of it.

You've got mail ...

Hi hybride,

I assume you heard from Dogber that indeed his driver causes the problems you experience ?
It will be solved in the next release, he says.

That should make you happy !