Topic: Suggestions for 3.9

[saga]

24 bit data in a 32-bit package

What would be the difference from 32-bit output? Anything having a lower resolution would be padded anyway.

[Alt]

It may improve sound quality.
Some devices can't accept pure 24 bits (can be checked with WASAPI event and KS outputs) but for some reasons can accept 32. And since most DACs don't have real 32 bits (only 24 or less) this looks like a reasonable workaround.
Confirmation of the problem from JRiver forums:32 bit package to 24bit hardware.

[Chinese Sausage]

Even if the Wine Project somehow figures it out to emulate XMPlay well in Linux

I'm pretty sure XMPlay is not in their top priority list of programs to get running, so if you want to help, you should report your precise findings of where XMPlay fails to function as expected to the WineHQ bug tracker. This will at least increase the change of the issue getting fixed.

I will look up to it. Thank you for the advice Saga. I really want this excellent Windows software to work in Linux as well.

[saga]

It may improve sound quality.

When choosing 32-bit output, XMPlay will already have to pad anything that has less than 32 bits, so please explain what exactly you imagine to be improved by such a setting? The DSP will cut off the lowest 8 bits either way, no matter if they contained silence or not.

Some devices can't accept pure 24 bits (can be checked with WASAPI event and KS outputs) but for some reasons can accept 32

Yeah, because noone wants to deal with the mess that is 24-bit data. 32-bit with 8 silent bits are just so much simpler to handle.

[Alt]

When choosing 32-bit output, XMPlay will already have to pad anything that has less than 32 bits

Sounds like you're saying that option of ASIO plugin "Use optimal resolution (else pad to it)" is useless. Presence of such option in xmplay and other players makes me think that you're not fully correct and there's some difference between "32 bit" and "24 (in 32) bit" resolutions for commonly used audio (with less than 32 bit data).

The DSP will cut off the lowest 8 bits either way, no matter if they contained silence or not.

Wouldn't be easier for DSP to handle with empty bits instead of cutting some actual data?

[saga]

Sounds like you're saying that option of ASIO plugin "Use optimal resolution (else pad to it)" is useless.

Not really, because first off it tells XMPlay what it thinks to be the most efficient or best-sounding bit depth it can handle.

Presence of such option in xmplay and other players makes me think that you're not fully correct and there's some difference between "32 bit" and "24 (in 32) bit" resolutions for commonly used audio (with less than 32 bit data).

Then what should this difference be? Let's just sum it up:
- The driver has to do something with the lower 8 bits. It can discard them or round them or whatever. Either way, whatever data is "down there" doesn't really matter because you won't find a DSP that will practically reach this limitation, and the dynamic range of the human hearing is too low to hear that anyway.
- Even the ASIO SDK states for the "x in 32 bit" options: "these are used for 32 bit data buffer, with different alignment of the data inside. 32 bit PCI bus systems can be more easily used with these" - meaning that all of these options are just meant for applications and drivers that would like to handle their audio in x-bit resolution (x for example being 24), but that x is simply too inefficient to handle on the CPU.

Wouldn't be easier for DSP to handle with empty bits instead of cutting some actual data?

Not really. When you don't read a value, it doesn't matter what's in it.

[mrbumpy409]

OpenMPT recently implemented the same panning algorithm used by FT2 for playback of XM files. More info here.

I've always been able to hear a difference between FT2's panning and XMPlay. Perhaps XMPlay could implement the FT2 panning law for even ballsier-accurate playback? Or does it already do this and I just need to have my ears checked?

[saga]

Actually, I've already "suggested" that in the bug report thread, including the needed formulas and an example module.

[amit]

How about using MMCSS (Multimedia Class Scheduler Service) to prioritize playback in modern windows systems (since Vista) , and if possible allow the user to choose his own MMCSS profile of preference?

Thanks.

[Azevedo]

An improved layout on the "options/settings" window with a quick description on the status bar for options as the mouse hover them (just like fb2k).
I think the options window is too small for the amount of options it holds, thus the layout is currently too supressed and confusing.
Why not put "internet streaming" options in a new section in the left panel instead of stuffing it in "miscellaneous"?

Seems that the settings windows was layered thinking of a 640x480 window. Who on earth still uses a 640x480 desktop resolution?

 

[Ian @ un4seen]

Another thing I noticed is that it's difficult to enqueue tracks from the find dialog using merely the keyboard. Using space, you can play the selected track, however enqueuing is only possible through the context menu (I know it can be reached through the application key, but that's clumsy). Using something like ctrl-space to enqueue tracks from the find dialog would be a nice improvement.

Here's an update that adds the option of queuing via shift+space (also shift+double-click)...

   www.un4seen.com/stuff/xmplay.exe

It would be really useful if overriden tags were preserved for sub tunes when splitting them. Right now, you have to copy them over manually from the original library entry to the sub songs.

The update above should copy overridden tags over to the separated subsongs, so long as the subsongs haven't been scanned previously. If you have already separated the subsongs, you will probably need to remove them from the playlist/library, restart XMPlay (so that it forgets about the separated subsongs), and then separate the subsongs again to have the overridden tags copied over.

How about using MMCSS (Multimedia Class Scheduler Service) to prioritize playback in modern windows systems (since Vista) , and if possible allow the user to choose his own MMCSS profile of preference?

I'm not sure that stuff will greatly benefit XMPlay, as XMPlay doesn't really require low latency output (so little processing delays aren't a problem), but the update above adds an "MMCSS" XMPLAY.INI option that you can set to a task name, eg. "MMCSS=Audio". Let me know if you find that it does help.

[saga]

Thanks a lot!

[amit]

How about using MMCSS (Multimedia Class Scheduler Service) to prioritize playback in modern windows systems (since Vista) , and if possible allow the user to choose his own MMCSS profile of preference?

I'm not sure that stuff will greatly benefit XMPlay, as XMPlay doesn't really require low latency output (so little processing delays aren't a problem), but the update above adds an "MMCSS" XMPLAY.INI option that you can set to a task name, eg. "MMCSS=Audio". Let me know if you find that it does help.

Usually that is true , but glitches and buffer underruns still can occur at higher sample rates such as 96khz and especially 192khz. I have tested two profiles "MMCSS=Playback" and "MMCSS=Pro Audio" and from my short test it seems xmplay runs smoother. Maybe it is placebo affect but audio even seems to sound cleaner  especially with "pro audio" profile.

[Dotpitch]

Usually that is true , but glitches and buffer underruns still can occur at higher sample rates such as 96khz and especially 192khz. I have tested two profiles "MMCSS=Playback" and "MMCSS=Pro Audio" and from my short test it seems xmplay runs smoother. Maybe it is placebo affect but audio even seems to sound cleaner  especially with "pro audio" profile.

MMCSS should only change the priority of CPU and I/O operations, so I wouldn't expect it to change the audio quality. Can you somehow prove XMPlay runs smoother? Because it would be interesting to know when XMPlay can glitch without MMCSS.

[saga]

It might be useful to have a "shuffle" context menu entry for the playlist. Currently I have a shortcut so that I can e.g. shuffle my queue when needed, however it's really stupid when I hit that shortcut accidentally, as then my whole "carefully crafted" (read: historitcally grown) playlist gets shuffled. Or as an alternative, the shuffle shortcut should only apply to selections..?

[Ian @ un4seen]

Or as an alternative, the shuffle shortcut should only apply to selections..?

When multiple playlist entries are selected, the shuffle shortcut should already only affect those selected entries

If you do accidentally shuffle the entire playlist, it should be possible to get it back to how it was via the "List - Undo" shortcut (Ctrl+Z by default).

[saga]

When multiple playlist entries are selected, the shuffle shortcut should already only affect those selected entries

Correct, and I kind of wanted to only have the shuffling happening when there is an actual selection. But that undo shortcut makes that unnecessary, I wasn't even aware there was such a shortcut!

[mingle]

Haven't read the entire thread, so forgive me if this one's been proposed already...

How about a "fade out" when closing/exiting XMPlay?

So the song fades (selectable rate?) upon exit, rather than an abrupt cut-off of the sound.

Cheers,

Mike.

[Alt]

I'd like to see option 'Loop list' in the 'Loop track' context menu of the main window. Sure I can open 'extended playlist' and select it there but I'm using skins with embedded playlists ( LunaLamfam, XMPlayer 8 ) so that's just an extra actions.

[Dotpitch]

I'd like to see option 'Loop list' in the 'Loop track' context menu of the main window. Sure I can open 'extended playlist' and select it there but I'm using skins with embedded playlists ( LunaLamfam, XMPlayer 8 ) so that's just an extra actions.

XMPlayer 8 has a button for that, just below the playlist panel, but LunaLamfam indeed does not have that button.

I'm actually surprised there is no shortcut to toggle list looping.

[Alt]

Dotpitch,
There's probably some misunderstanding.
On the main window I see "loop" options only for one (current) track.
Here's screenshot:

[piovrauz]

mingle asked about "How about a "fade out" when closing/exiting XMPlay?". I'd like to +1 to that.
Also, I'd like to ask if it could apply to seeking too, obv all of this would be optional.
I think WA has decent lenghts for seeking fades, dunno about closing, but it could be used as an example.
Sorry if I often take WA as an example for things, but it's easier to explain something using an example...


about the looping: doesn't that menu take care of list and song looping? and I use its shourtcut...
did I get something wrong?

[Alt]

piovrauz,
Menu on the main window ("Loop track", below) is for a single track looping, menu on the 'playlist' window (above) is for a playlist looping. I just want to have that 'List loop' option on the "Loop track" context menu.

[Dotpitch]

On the main window I see "loop" options only for one (current) track.

Ah, you're right.

[Jace]

How feasible/bloaty would it be to have XMPlay (or a plugin..?) upmix stereo (or mono) files to all available speakers?

I currently am doing it the way you're supposed to, with DirectSound output, letting my soundcard (onboard Realtek) drivers do the dirty business. But as shite as they are, I barely get any sound from the rear normally until the song hits a point where it goes on a certain frequency or something, then I'll just get a sudden loud worbled phased filtered reverbed glitchy noise which barely has any resemblance to the song actually playing. Optimally (for me) it could just send front left speaker data to rear left and front right to rear right.

Or are there other methods to achieve what I'm after?

Bumping this request, as I have specific example files and fluff.

Song in question: Dil-Don't - Stripe Summer (First minute of the song)
Same song on youtube: Linkum.

My output setting: DirectSounds - Speakers (Realtek High Definition Audio), 48000Hz sample rate, 1.000s buffer, stereo channels, apply sample rate to all formats enabled, src quality slider to the maximum, resolution: 32bit, downmix multi-channel disabled, dithering and noise shaping enabled.

Anywho, the sound I get: Outputs
Explanation: I played the same song with XMPlay and from the youtube link. I shut down the front channels and recorded the rear speaker output with an external recording device. The first minute of the file is what I get when the song is played via XMPlay, second minute is the output when playing the song on youtube.

If I've understood things right, XMPlay actually relies on the soundcard drivers to produce the sound for the rear speakers, which in my case is more or less utter garbage. Which is why I really would love for the program to have its own channel upmixing. Even if it's straight clone of front right to rear right and front left to rear left or something similar. Getting music from rear speakers would be better than getting random noise out of 'em.