next »

[Synetech]

Hi,

I couldn't find any consolidated posts for reporting bugs so...


RESOLVED

I've got an official Duke Nukem Forever theme song MP3 and it consistently crashes XMPlay (but not WMP or WA).  I checked it with MPTrim and the only error it seems to have is an incomplete last frame (probably a bad tagger).  I can send it to you to check if you want it.

Or you can get it here: http://www.fileplanet.com/83047/80000/fileinfo/Duke-Nukem-Forever-Music-Clip

[Bistzack]

I've got an official Duke Nukem Forever theme song MP3 and it consistently crashes XMPlay (but not WMP or WA).  I checked it with MPTrim and the only error it seems to have is an incomplete last frame (probably a bad tagger).  I can send it to you to check if you want it.

Or you can get it here: http://www.fileplanet.com/83047/80000/fileinfo/Duke-Nukem-Forever-Music-Clip

This mp3 is one of those I cannot add to the playlist. That is why I did it with XMPlay 3.1 and then tried to play it with XMPlay 3.2. It crashes for me too.

I hope you aren't angry Synetech I uploaded dnfe3theme.zip file. I myself had to wait in que for one hour in order to download it.

[Ian @ un4seen]

XMPlay didn't like the very large ID3v2 tag. It should be sorted now...

   http://www.un4seen.com/stuff/xmplay.exe

[Synetech]

XMPlay didn't like the very large ID3v2 tag. It should be sorted now...

   http://www.un4seen.com/stuff/xmplay.exe

That did it, nice job.

[Synetech]

RESOLVED

This one isn't so much of a bug as a general wonder...ing...ment.

If I stop everything then check the task manager, I see the CPU usage line hovering around 0 (2-5%).  If I then run XMPlay, the CPU usage line jumps to about 20% and stays there until I quit XMPlay.  The thing about it is that it's the red kernel line that's at 20% and the green CPU line is stuck floating on top of that.

I don't think it's a hotkey thing since neither Winamp nor HotkeyMaster exhibit this behavior.

I think it may be some kind of a media thing since most of the programs that do this are media apps: XMPlay, ATI TV (MMC), WMP, and so on.  Of course Winamp is also a media player and it doesn't do it so I'm thoroughly confused.

Here's some charts to make things clear:

[Ian @ un4seen]

If I stop everything then check the task manager, I see the CPU usage line hovering around 0 (2-5%).  If I then run XMPlay, the CPU usage line jumps to about 20% and stays there until I quit XMPlay.

Is that even without playing anything? Do you have the vis window open?

[Synetech]

Sorry, I forgot to specify that; it's like that when it's completely idle, not playing, no vis window, not scrolling the song title, minimized to tray...

[Ian @ un4seen]

That's strange. Have you tried removing all plugins? (leaving just XMPLAY.EXE on it's own)

[Synetech]

Not yet, but I'll run some tests tonight.

[Synetech]

That's strange. Have you tried removing all plugins? (leaving just XMPLAY.EXE on it's own)

I've got good news and bad news.

The good news is that you don't have to do any work because it's not a problem with any of your work.   

The bad news is that it was the Skale plugin.  The newer version (.80) makes it a little better (instead of sucking cycles on startup it waits until you access the file-info) but it still sucks cycles.

Well, I never really used that plugin anyway.


Now, I have to keep an eye on my temps to see if they are lower after running XMPlay for a while (I'm not sure if kernel times contribute to heat).

[Torkell]

Now, I have to keep an eye on my temps to see if they are lower after running XMPlay for a while (I'm not sure if kernel times contribute to heat).

Not really, as kernel times are just the portion of CPU use spent inside the Windows kernel. The green line is total usage, including kernel usage.

[Synetech]

Not really, as kernel times are just the portion of CPU use spent inside the Windows kernel. The green line is total usage, including kernel usage.

CPU cycles are CPU cycles, you would expect it to generate heat no matter who used the cycles but I've found that I can have high kernel times without the temps rising whereas application use of the CPU jumps the temps very fast.  It might have to do with efficiency or with how TaskMgr calculates things.

[Torkell]

Not really, as kernel times are just the portion of CPU use spent inside the Windows kernel. The green line is total usage, including kernel usage.

CPU cycles are CPU cycles, you would expect it to generate heat no matter who used the cycles but I've found that I can have high kernel times without the temps rising whereas application use of the CPU jumps the temps very fast.  It might have to do with efficiency or with how TaskMgr calculates things.

It depends on what the CPU is doing - different instructions tax the CPU differently.

[Synetech]

RESOLVED

I'm not sure if this is actually a bug but the output settings in the Device tab have no effect on the resulting WAV file created by WAV Writer.

For example, if you set the device to WAV Writer, set it to Mono/22050/8 (for whatever reason) then play a Stereo/44100/16 file, the WAV file will also be Stereo/44100/16 instead of Mono/22050/8.

[Synetech]

RESOLVED

If you start playing a MIDI file then stop it, it will start playing from start of the file again but this time the XMP display (time counter, VU meter, etc) don't run.  (Yes I made sure that it's a MIDI not a MOD, even so, I still made sure there was NO loops active).

NEW BUG

Possibly related to the above bug item, XMPlay uses very little CPU (~0-1%) normally, but as soon as you start playing a MIDI file, the CPU usage jumps to about 20-25% and stays like that until you quit XMPlay.

[Synetech]

RESOLVED

I'm not sure if this one is a bug either but when you set the file type in the open file dialog to XMPlayable it only lists (what look like) file types natively supported by XMP, it does not include any of the filetypes supported by the installed plugins.

Is that normal?

Is there some sort of "All Supported Types" option?

[Alexsource]

NEW BUG

I'm not sure if this one is a bug either but when you set the file type in the open file dialog to XMPlayable it only lists (what look like) file types natively supported by XMP, it does not include any of the filetypes supported by the installed plugins.

Is that normal?

Is there some sort of "All Supported Types" option?

If i remenber correctly, this have been there for a while. The all supported types thingy had been asked for many times.

[Synetech]

If i remenber correctly, this have been there for a while. The all supported types thingy had been asked for many times.

Oops, I forgot to search about it.  I see; so it's not a bug but a request.

[Dotpitch]

NEW BUG

I'm not sure if this is actually a bug but the output settings in the Device tab have no effect on the resulting WAV file created by WAV Writer.

For example, if you set the device to WAV Writer, set it to Mono/22050/8 (for whatever reason) then play a Stereo/44100/16 file, the WAV file will also be Stereo/44100/16 instead of Mono/22050/8.

note: The sample rate setting only applies when playing MOD formats.

xmplay doesn't resample the input if it doesn't have to. only when your soundcard can't keep up with the format (like when playing 96 kHz 32-bits 6ch and you have a standard Soundblaster) it will adjust it to what is possible. since the wav-writer doesn't have that problem (you can write anything you want) it doesn't resample and output the original quality.

[Torkell]

I'm not sure if this is actually a bug but the output settings in the Device tab have no effect on the resulting WAV file created by WAV Writer.

For example, if you set the device to WAV Writer, set it to Mono/22050/8 (for whatever reason) then play a Stereo/44100/16 file, the WAV file will also be Stereo/44100/16 instead of Mono/22050/8.

Tested here with 3.2.0.6 (28 april, 254556 bytes). Works as expected with a MO3. With a MP3, only the bit depth setting is preserved (rest is whatever the file was encoded at), which makes sense in a way (the Device tab has a note saying that the sample rate only affects MODs).

If you start playing a MIDI file then stop it, it will start playing from start of the file again but this time the XMP display (time counter, VU meter, etc) don't run.  (Yes I made sure that it's a MIDI not a MOD, even so, I still made sure there was NO loops active).

Are your MIDI settings configured correctly? I'm assuming you're using the winamp plugin. It needs to be set to use DirectMusic and to use winamp's output, otherwise you'll have problems.

Testing here (with same version)... I've noticed that when you stop the MIDI file the plugin doesn't reset the MIDI channels. So if you then click play without unloading the file first, it'll finish playing the bar you stopped it at and then start from the beginning. There's also a similar effect when seeking, probably due to how the plugins handles seeking in MIDIs.

Possibly related to the above bug, XMPlay uses very little CPU (~0-1%) normally, but as soon as you start playing a MIDI file, the CPU usage jumps to about 20-25% and stays like that until you quit XMPlay.

Here XMPlay uses 5-10% (Athlon 1.3GHz) when a MIDI file is loaded and/or playing, and that drops to about 0% when the file is unloaded (press Stop twice to unload a file). Again, check your plugin settings.


Of course this could all have appeared in one of the new builds of XMPlay. Ian, could you start adding build numbers to XMPlay?

Edit: Typoed. It's "bit depth" not "bitrate" that's preserved.