0.9u-6 -- Loud pop when playing next track

[PeterSt]

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 ?

[edward]

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 still don't understand why you thought it would be the other way around. You said:

When you wish to check whether all is back to normal, test this with the Mem checkbox checked;

Just to be clear again - the pop does NOT occur when I check Mem.

And forgive me I did not check the entire list, but indeed it occurs at the end of the first track as well as the second. (And these are all WAV files)

[PeterSt]

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

[PeterSt]

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

[edward]

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 sent you a PM.

[PeterSt]

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.