Fantastic! Good thinking. "EndPadding=35" does the trick. Thanks so much for your help and patience!

OK. Here's another little tweak of the padding for you to try...

   www.un4seen.com/stuff/xmplay.exe

Let me know if there's any change.

It still gets cut off early on normal playback, I'm not sure if it sounds any different from the previous versions.

Playback in XMPlay while recording in Audacity is improved, but it seems like it cuts off a very tiny bit every 8-10 times or so.

Just to be sure, is the "stuff" waveform with the last update (3.6.0.63) that I posted? It looks very similar to the previous (3.6.0.62) recordings.

Yes, it used 3.6.0.63. The 3.6.0.62 recordings cut off a bit earlier, a lot like those from the release version. I can make some more recordings for comparison, if that would help.

Here's a .wav using 3.6.0.63. As I mentioned before, the cutting/cropping occurs irregularly: there are several times in the file where it works as it ought.

Well, now another oddity has come up. When recording--I'm using Audacity--the release version cuts the way it normally does. However, when recording, the newest "stuff" version seems to work part of the time and other times crops off just a bit at the end. It still seems to playback just the same as the release version (i.e. it clicks the same way) when not recording in Audacity.

Attached is a visual comparison of one of the recorded times when it cuts prematurely.

Measuring the time difference between them for a few times, I got 23ms (1024 samples), 17ms (762 samples), and 23ms (1022 samples).

I also encountered another oddity when experimenting with the audio buffer lengths--it seemed that the buffer at its shortest setting (.100s) played more of the waveform--though it still cut off prematurely--whereas higher buffer settings played less. That may have been something of a statistical fluke though, I haven't tested enough to tell.

Dotpitch and Ian, thanks for the help, sorry for the delay in response.

Ian, the executable you provided doesn't seem to fix the problem for me, unfortunately.

Dotpitch, here is a link to a WAV recording of my audio playback. It uses the executable Ian linked to, and it uses the same settings as before (WASAPI, "Use highest resolution"). As you'll see, the waveform is visibly cut off prematurely.

"Use highest resolution" was already ticked. (Turning it off doesn't change anything either.)

However, turning on "exclusive mode" (checking the "Enable" box) for WASAPI yields correct playback. Interesting. ASIO as a protocol takes exclusive control of the device too, right? Still, other applications can play successfully with a non-exclusive mode: Audacity plays the file fine using DirectSound and MME; ditto for Wavosaur and Audition using MME.

Anyhow, here's the general info tab:

Title 0005_hostess-x-01.wav
File 0005_hostess-x-01.wav
Path E:\Sounds\tmp
Size 53932 bytes
Format WAVE (PCM)
Bit rate 1411 kbps
Sample rate 44100 hz
Channels 2
Resolution 16 bit
Length 0:00
Output 44100 hz - stereo - 32 bit

Ah, the plot thickens. After a few more tests, I determined a few things: first, that adding extra silence to the start of the file doesn't change anything, whereas adding some amount to the end will make it play back smoothly. (I'm not sure exactly how much, but it's less than half a second, more than ~50 samples (~1 ms)). So it definitely seems related to there being a burst of "sonic activity" right before the file ends.

Perhaps more importantly, I discovered that the errors vanish completely (that is, everything plays correctly in WASAPI non-exclusive mode, in DirectSound, and in MME) if I open Wavosaur at the same time, load any audio file and then play it in Wavosaur. As long as Wavosaur's still open after that, XMPlay plays with no clicks (even after closing the file in Wavosaur). If I try this same trick with VLC, it doesn't quite work: there's still a click after loading and playing something in VLC, if the audio in VLC has stopped by that point. But if VLC is still playing audio while XMPlay plays, there's no click.

So, my layman's guess here is that it's got something to do with whether the audio device has been released yet or not. Wavosaur, apparently, doesn't fully release the audio device after playback, whereas VLC does so immediately after it finishes. So perhaps XMPlay's clicking might be caused by letting go of the device just a little bit too quickly, or something?

Ah, thanks, didn't know about those. Outputting via ASIO fixes the problem, but it still makes the click with WASAPI, DirectSound, and the default MS mapper--even with the newer stuff version.

It happens both when it's the only file in the playlist and when there's another file in the playlist too.

Okay, I just posted this as a separate thread before I realized I probably should have posted it here. Anyway...


I'm using XMPlay 3.6.0.1 on Windows 7 x64, and I've encountered an irritating little problem: the ends of certain audio files--I think it's just short ones, but I haven't experimented enough to be sure yet, I'll do some more testing later--cause a big click noise, as though there were a DC-offset problem or some other scenario where output jumps abruptly from one extreme to another. The example for this case happens to be a 44.1khz stereo 24-bit .WAV file, which I've uploaded here. I'm positive that this is not a problem with the wave file itself, because Adobe Audition, Wavosaur, and for that matter Windows Media Player will all play it back without a problem. (And because viewing the waveform in the aforementioned Audition or Wavosaur shows nothing that should be causing such a click.)

I have the crossfade between tracks option off, and I'm hoping that the solution isn't to enable a fadeout setting somewhere in XMPlayer, because I'm interested in fidelity to the original file--in a situation where there really IS a DC offset problem or interrupted waveform at the end of an audio clip, I want to be able to hear that.

If you don't get a click on the first try, you might try replaying it a few times, it does it a little bit sporadically for me.

Would appreciate any insight!

--Edit, whoops, guess this should have gone in the big bug thread, sorry...--

Hey, I'm using XMPlay 3.6.0.1 on Windows 7 x64, and I've encountered an irritating little problem: the ends of certain audio files--I think it's just short ones, but I haven't experimented enough to be sure yet, I'll do some more testing later--cause a big click noise, as though there were a DC-offset problem or some other scenario where output jumps abruptly from one extreme to another. The example for this case happens to be a 44.1khz stereo 24-bit .WAV file, which I've uploaded here. I'm positive that this is not a problem with the wave file itself, because Adobe Audition, Wavosaur, and for that matter Windows Media Player will all play it back without a problem. (And because viewing the waveform in the aforementioned Audition or Wavosaur shows nothing that should be causing such a click.)

I have the crossfade between tracks option off, and I'm hoping that the solution isn't to enable a fadeout setting somewhere in XMPlayer, because I'm interested in fidelity to the original file--in a situation where there really IS a DC offset problem or interrupted waveform at the end of an audio clip, I want to be able to hear that.

If you don't get a click on the first try, you might try replaying it a few times, it does it a little bit sporadically for me.

Would appreciate any insight!


Specs summary for convenience:
XMPlay 3.6.0.1 on Windows 7 x64
Using an M-Audio Delta 1010lt card (not sure if that's relevant... I don't seem to get any choice about using ASIO/WASAPI for playback, though. My options are just "Microsoft Sound Mapper", the Delta's outputs, and the wave-writing things.)
Changing playback sample rate and bit-depth doesn't have any effect, nor does adding a longer buffer (not sure if that would help anyway, but I tried it).