next »

[saga]

For ID3 tags, "Synthpop" should be written without a capitalised "P". It might be stylised like that in the old ID3 tag list, but that's not how you usually capitalise the genre.

[Ian @ un4seen]

Some time ago I came across ZX Spectrum module music decoder: (I was unable to find it on the net, so here's mediafire link)
http://www.mediafire.com/?wevsuefiv94t42i

It works flawlessly in Winamp2 but when you play something through it in xmplay it sounds weird. Any ideas?

The plugin is asking XMPlay how much sample data can be accepted, but it then appears to ignore what was said and it ends up providing too much data, resulting in some data getting dropped and an audible skip. I'm not sure sure what can be done about that. I tried increasing the size of the buffer that receives the plugin's sample data, but it still eventually overflowed.

For ID3 tags, "Synthpop" should be written without a capitalised "P". It might be stylised like that in the old ID3 tag list, but that's not how you usually capitalise the genre.

I'll update that for the next update.

[tails_]

Just found CUE sheet which XMPlay doesn't seem to like for some reason :\ (well, maybe DCP flag)

http://www.mediafire.com/?5ne84sn78i1u86y

[Ian @ un4seen]

XMPlay currently ignores/rejects CUE sheets that don't include any TITLE info (like your example). I'll look into changing that for the next update.

[icelizarrd]

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!

[Dotpitch]

Please try the latest stuff version. You can get ASIO and WASAPI output using the respective plugins from the XMPlay page (scroll down, below the skins are the plugins).

Does it happen when that file is the only file in the playlist and you keep repeating it? Or does it only happen when there's another file in the playlist as well?

[icelizarrd]

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.

[Dotpitch]

Good that it's fixed with ASIO . For WASAPI, could you tick Use highest available resolution and try again? Also, could you post the contents of General tab of the Info Window (right-click it to copy) while playing that file?

[icelizarrd]

"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?

[Dotpitch]

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?

Both ASIO and WASAPI exclusive are able to use the device directly, while the default output, Soundmapper, DirectSound and WASAPI non-exclusive have to pass the audio to the Windows mixer.

Anyhow, here's the general info tab:

Could you record how this files is played back on your pc? At least the sample rate of the device matches that of the file, so this problem shouldn't be because of re-initializing the sample rate at the start of the track. Apparently it's some other thing that happens during initialization of a track.

[Ian @ un4seen]

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

I did some testing with your file, and I was able to reproduce the problem on Win7 and Vista; it doesn't appear to happen on XP. It also doesn't appear to be so much related to when XMPlay releases the output device as to what's at the end of the data that's played, ie. the problem still happened with most devices if the device releasing was delayed (even by several seconds). That wasn't the case with every device that I tried (the delay did help with an onboard Realtek), so it also appears to be somewhat driver dependent.

As the problem appears to be related to the final sample data, here's an update that will add a bit of silent padding to the end of the final track on Vista/7...

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still get the problem happening with it.

[Bistzack]

The last update freezes XMPlay when a scroll wheel is used to if I turn the volume up / down.

[Jimmy Neutron]

Same here.  After the first volume change, the music keeps playing but everything locks up.  Have to kill the xmplay*32 process in Task Manager to regain control.

Win7 x64 if that matters.

[saga]

Not happening here, using Win x64 and the DSound driver.

[Jimmy Neutron]

Changing output from "Speakers (High Definition Audio" (while you're there, note the missing end-paren) to "WASAPI (High Definition Audio Device)" solved the problem.

[icelizarrd]

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.

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

Yep, that doesn't look good. The point where XMPlay cuts off is not always the same, by the way.

[andy2004]

xmplay 3.6.0.62 crashes on my windows 7 64bit, 3.6.0.61 and before didnt, crashes when i slide the volume control up/down not via the mouse.
removed all .dll files from the xmplay folder to make sure it wasnt that. changed output from sound mapper to Realtek high def no change.
music continues to play in the background until I kill the process.

[Ian @ un4seen]

The last update freezes XMPlay when a scroll wheel is used to if I turn the volume up / down.

Oops! The update did indeed break volume adjustment with the default output system on Vista/7. Here's an update to correct that...

   www.un4seen.com/stuff/xmplay.exe

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.

It looks like the waveform is up to 10ms short in that, so the padding length has been increased by 10ms in the update above. Please see if the problem still happens with that, and if it does, does the waveform still appear to be chopped at the same point? Also, if you switch back to the release version, at what point is the waveform chopped with that?

[garson]

Again bug with strange letters.


This was u bug that I've reported sometime ago, it was fixed. Just for this one track on this internet radio.

Latest stuff, 3.6.0.63.