XXHighEnd

Peter, I have finally just played with 0.9u-6 and there is a loud pop when it plays the next track. IOW on a playlist with a few songs, it "pops" between each song. The last version I was using was 0.9u-3 and it does not do it with that version. Could it be a bug with the gapless function?

FWIW, if I stop and select the next song and then press play - there is no pop. (It only happens on continous play)

With what setting (acc. Double etc.) and file (rate etc.) is dat ?

Edward, i also suffer with plop's/cracks
Just a question. Are you using the native windows usb drivers or did you install a different driver?

All my settings are in my sig. (set to DAC is 24/96)

Files are 16/44.1

I'm using the M-Audio driver.

I don't hear cracks, just one loud pop between songs.

hybride, I'm fairly sure that you talk about something else. Please don't mix up things in that case.
But if you experience the (100% !) same as Edward just explained, then please say so !!

Edward,

For technical reasons (hence knowing the program) I can't think of anything else than gapless indeed. The strange thing is though, that I've been playing with the same settings yesterday for quite some hours, and nothing of the kind happened. Ok, one difference : I didn't use Invert.
Can you please check without Invert ?

Otherwise the only technical reason I can imagine, is that your (e.g. FLAC) files are converted late (slow system), that holding back playback for a while, and *then* the DAC is kind of re-initialized. Otherwise it's continues play.

But hold on. I think I can reason it out;
If that's an indeed "gapless" playing album you have at hand (like a live album), I could have made the mistake to apply Invert twice. Difficult to explain, but it would come down to one track playing Invert, the next not, the next again Invert, etc. Now *that* would cause the loud plop, because the voltage will go from minus x to plus x in one straight go.

So indeed, try without Invert and let me know.

I did indeed try it with invert and without. Same behaviour.

Also, these are WAV files (not FLAC) and it is not a "gapless" album. The playlist consists of random songs from different artists.



. . . time to sleep now.  :sleeping:
I'll try more settings tomorrow.

In that case I really can't think of what happens. If I only had it myself ...

As a side note with hardly a chance that it's related : not only me but others too reported similar, but exactly the other way around as what you describe : at the first initialize of the Soundcard/DAC of a higher samplerate setting, there's a 100% volume pop. This is not related to the fact that the soundcard/DAC already was set to that setting; it keeps on doing it, though randomly. This probably has been so always (with me anyway), but only occurs now because of the pre-amp being eliminated.

From your description I perceive all as the same plop I (and others) have, but in your case it is during playing. When it's not about the Invert I can't think of anything else, and there is really no way the DAC stops in between songs.

Ok ... I have one other idea;
Things have been changed according the calculation on where the music data starts in the file. I did not play attention to gapless, but I recall a few times the song started abrubtly. Like not in the beginning. If this is indeed the case, you should be able to notice it just by a gapless (live etc.) album. Thus, then gapless wouldn't work properly anymore ...
I put my horses on this one. :)

Ok sorry, don't want to confuse things, but only interested in possible relations with drivers and any unwanted behaviour.

Well . . . I tried every combination I could think of, and now I'm leaning towards the problem being about the calculation of where the song ends.

As I said before, I only tried with 16/44.1 files. Here are the combinations.

Invert on.
Invert off.
Double (to 88.2) (with DAC is 32/96 & 24/96 and DAC needs 32 bits)
Double/Upsample (to 96) (with DAC is 32/96 & 24/96 and DAC needs 32 bits)
Double and Upsample off (with DAC is 16/44.1)

All combinations exhibit the pop.

So I tried playing two back to back tracks from an album (that run together) and NO POPs. Also, in this case, the gapless was seamless (it did not start abruptly). OK, so again I tried some more different random tracks and NO POPs. So it seems this is track dependent. So I tried multiple combinations with the "problem" tracks, and the POP only exhibits when it is the previous track (even when followed by a "good" track). When I play a "good" track first, followed by a "problem" track, then I get no pop. So clearly the problem with these "problem" tracks is in the ending. I opened a couple of these in Nero WAV editor and did not see anything unusual at the end of the track (no spikes, etc.).

Since these "problem" tracks do not exhibit pops in 0.9u-3, is there anything different with 0.9u-6 about calculating the length of a song?


edit: FWIW when the "problem" track is the only one in the playlist it does not pop when it ends.

Actually, yes. I now take the physical length of the file (track), to be independent of often wrong header data.
Now what ...

Ok, I think I can find another means of doing it right. I hope ...

Thanks a bunch Edward !
Peter


PS: Didn't you see a lot of zeros near the end of such a track ? I saw them before (actually my glitch detection saw it :) but now I wonder whether that should be skipped for some reason ...

Loud pop is now gone with 0.9u-7, but only if I check Mem. Unfortunately the SQ is better with Mem unchecked.

Can I have the best of both worlds?  ;)

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

Why do you think it's strange? I thought you expected that the "pre-processing" would result in better SQ.

Here's my screenshot: (And yes, I am using Vista - don't worry about the look of the window, I have Visual Effects set to "Adjust for best performance")

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:

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)

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

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

I sent you a PM.

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.