If you get an error dialog on loading XMPlay, but it continues to run fine, then it's probably a plugin that is crashing... try removing them one by one, until you find the culprit.

Please upload the MP3 file to have a look at...

     http://ftp://ftp.un4seen.com/incoming/

Is this with any vis plugin(s) in particular, and if so, which?

Also, does Windows give any details on the crash - the location/etc?

Yep, that's probably pretty much the only 100% reliable way (if you can trust the manufacturer ) ... It is possible to query what the drivers support, but that's not necessarily what the card itself outputs - the card or drivers may resample too.

Just a quick question while we are here... I set XMPlay to 96000Hz and 32-bit to listen on the home entertainment system, but I doubt that my soundcard [ cheap SB Live Plat ] can handle that. Is this a bug?

On modern Windows (with WDM drivers), Windows will automatically resample it to what your soundcard supports - you won't hear any benefit from using a sample rate or resolution higher than what your soundcard supports, so you may as well set the output to what your card does support to save a bit of processing ... in your case, that's 48000hz 16-bit.

Unfortunately, I'm unable to play that WMA file because it is protected... if you ripped the track from a CD, can you re-rip it with the "Personal Rights Management" option disabled?

Check that you still get the problems with the new file before uploading

hmm... that's strange. I see no logical reason for that to happen, as the decoded sample data from all formats goes via the same "route". Does the problem happen with both the "WAV Writer" and "WAV Writer - normalize" device options, and with all of 8/16/24/32-bit?

Also, how are you checking the WAV files? Can you see the glitches/skips in a waveform view of a sample editor?

[Blue III]

Got to be Blue III, surely?

nice work Bruce

[ls -lR]

The ls -lR FTP command (or ls -lRa to include hidden files) will give you what you want.

The thing I can't decide is which options should be included, and how to arrange them nicely... if anyone wants to do that, and send me the resource file, they're most welcome to

I have been planning to add a dialog containing all the options before releasing 2.7a, but I've not yet decided on a layout for it. It wouldn't necessarily replace the options in the GUI - just replicate them in a single place, for peeps that can't be arsed to switch panels/etc...

Regarding the vis stuff... a "Restrict rendering" option has already been added, which basically makes it work as in the previous versions

From the XMPLAY.TXT file...

Interpolation switch - MOD formats only
   "Linear" interpolation "draws" a straight line between the samples,
   "Sinc" interpolation "draws" a smooth curve between the samples and
   requires more CPU power.

So, basically, interpolation joins the dots

Yes, it improves quality, though some old MODs may sound better without it (as that's how they were created).

| If the original WAV's optimal amp level was 64, there's a
| good chance that it contained clipped samples.

Isn't 64 the default?  In that case if it was also the optimal, clipping shouldn't occur, in my opinion.

If a WAV file contains clipped samples, there's nothing XMPlay can do about it - whatever was clipped is gone. So there's nothing to be gained by XMPlay reducing the amp level.

The exception is if it's a non-clipped floating-point WAV file, in which case XMPlay can reduce the amp level to stop it clipping, just as it does with the MPEG/OGG/MOD formats.

I never understood the way, that amp bar is working... WAVs play perfectly but OGGs and MP3s of that WAV are producing strange noises - no other player does that, duh.  

Upload please

If I have a 16-bit stereo 44.1kHz MP3/OGG/WAV, and I play it back at 32-bit 96kHz (or as near to that as the sound card goes), what happens to it. Does the interpolation affect it at all?

No. Firstly, XMPlay will play the MP3/OGG/WAV at 44.1khz - the sample rate setting only applies to MODs... in fact, so does the interpolation option

Also, I have a little problem with OGGs & XMPlay - I create a OGG (typically ~152kb/s) from a WAV file (that was from a CD), all at 16 bit 44.1kHz, and then play it back with XMPlay. When I play the OGG, XMPlay decides that 64 is too high an amplification setting. With the WAV, the AAR remains static on 64 quite happily. Why? The WAV was produced using RealOnePlayer, and the OGG using XMPlay and OGGENC.

If the original WAV's optimal amp level was 64, there's a good chance that it contained clipped samples. In that case it's very possible (likely even ) that a lossy compressed (OGG) version will clip slightly... you can check by writing a 32-bit WAV of it (with auto-amp disabled), and looking at that in a sample editor.

That skin config option (pos_infoframe) has actually been there since v2.5

ps: I also added it to the X-RD2506 config before compiling

Ah yes, now I can reproduce it on WinXP. I think it's a Windows/driver issue, as it does happen with Winamp too. The reason you may not have noticed it with Winamp is that it seems to only happens when you set the output to 24 or 32-bit, so you would have to use the MAD plugin to get it to happen.

I wasn't able to reproduce it on Win98 or 2K (though there is a small piece of the paused sound on 2K, but that's a known Win2K thing ) ... so it appears to be an XP problem. Are all of you with the "buzzing" using WinXP and 24/32-bit output?

Note, for those with a 16-bit soundcard, there's no real benefit in setting the output to 24/32-bit anyway

hmm... I'm unable to reproduce this "bzzz" thing here, on Win98 or XP. This is what I tried: I paused XMPlay, and then made one of the Windows sounds play (I tried opening a dialog and also navigating in Explorer), but the sounds played correctly. Should that have produced the problem?

What Soundcard/Windows are you all using? Also, can you reproduce the problem with Winamp? (using the Waveout output)

Kynes/BG, I'll look into that vis stuff.

As I mentioned before, the length scanning and "dead track" checking are performed at low priority, so won't take CPU away from anything else that needs it. So there's not really much to be gained by disabling them, but if you wish, you can disable the dead track checking at startup. Load Regedit, go to this branch...

HKEY_CURRENT_USER\Software\Un4seen Developments\XMPlay2

...and set the "CheckDead" value to "0".

[sd2-09.spc]

-Finally, some visualisations will now cause XMPlay to crash if they are resized (e.g. Hyperspec). Watch out for these.

Yep, unfortunately a few plugins don't much like being resized. I don't think anything can be done about that, so you'll just have to be gentle with them

I am realy glad to see the resizing option for the ViSes, but now the ViSes all stutter cause of thier memory usage. I have a small music machine that is coupled to my HiFi.  I did not mind the older Stretching of the vises,  they looked fine on the monitor and were responsive (some more so than on thier original Sonique)
Is it possible to have the Stretch option the same as for 2.6  but a Maximise button (or some setting) that uses the new 2.7 resizing functionality?

Maybe an option to restrict the rendering dimensions, above which it is stretched? I'll look into it.

"Remove dead" in XMPlay 2.7 doesn't remove non-existant local files not marked as "dead".

That was removed in 2.7, as XMPlay now checks all files in the list at startup. Though, I guess it could be useful if you delete files while XMPlay is running, so maybe I'll put it back

The file /incoming/sd2-09.spc is an MP3 for XMPlay so it doesn't let the SNESAmp plugin to play it. Please fix.

It's sorted for the next release.