next »

[ChemZ]

This has been suggested before but here goes... XMPlay needs an option for full file buffer (ala Foobar2K).

I know this isn't added to keep the memory usage low, which is all well and good. But what about people with memory to burn?

I don't do much on my computer except listening to 20-50megs files. Using XMPlay, the hard disk never stops spinning! I mean never! (Yes, my HD is suppose to stop after 3 mins). It gets noisy and waste power.

Currently I'm using Foobar2K which does allow full file buffer (allowing HD to spin down), that's the only reason I use it. But I really would like to switch back to simplier & smaller XMPlay. (WinAmp is not an option!)

At least have it as an option for people with modern computers and plenty of RAM.
(That way you don't have to use it, if you don't want to or need to)

Thank you!

[Pike84]

Why not - memory is dirt cheap these days, and modern computers support higher and higher capacities.

So +1 .

[oddiophile]

Here's another +1 for the 'full file buffer' option.

Every (old) PC running WindowsXP has at least 1~2 GB of RAM now, even the 'crappiest of crap' Atom netbooks.  Even the low-budget modern (Windows 7) PCs have at least 4 GB as standard.

Many users listen to really LONG mixes / podcasts / shows (2 hours minimum) or huge .WAV files and don't do anything else with the PC at the same time (they just relax, enjoy the music and leave their PC idle / in power-saving mode to keep the noise levels low). XMPlay constantly reads from the HDD and the PC rarely goes into low-power mode.

And what about playing files from CD and DVD discs? In this situation, the problem is even worse - imagine playing a 80MB .mp3 file from a CD on a DVD drive. With XMPlay, the drive keeps reading and spinning all the time. Not only the noise is unbearable, but the lifetime of the drive is being reduced as well.

Foobar2000 just caches the files into RAM and never spins the drive again when playing back the same files *again and again*. The cache size is user- adjustable, dynamic (it doesn't use the whole 256 MB if you play a 5MB file) and 'smart' (oldest files are flushed first). The memory is released when you close the player.

256 MB of cache is more than enough for most situations.

I don't want to use Foobar2000, but I'm forced to use it anyway just because of this option* (especially when playing back music files from optical [data] discs)

* OK, there's another little feature that makes Foobar2000 the king - the VST (fx) wrapper plugin

[Chinese Sausage]

XMPlay may not be king but it is definitely my favorite. High quality player.

[amit]

Recently I wanted to save a few lists for re-use at a later time. It wasn't that complicated but maybe it can be easier?

After the search history menu was implemented I thought : why not enhance the accessibility to recent playlists as well? Right clicking on the "save lists" button could bring up the last saved playlists and offer a quick load .

[Ian @ un4seen]

This has been suggested before but here goes... XMPlay needs an option for full file buffer (ala Foobar2K).

I know this isn't added to keep the memory usage low, which is all well and good. But what about people with memory to burn?

I don't do much on my computer except listening to 20-50megs files. Using XMPlay, the hard disk never stops spinning! I mean never! (Yes, my HD is suppose to stop after 3 mins). It gets noisy and waste power.

Currently I'm using Foobar2K which does allow full file buffer (allowing HD to spin down), that's the only reason I use it. But I really would like to switch back to simplier & smaller XMPlay. (WinAmp is not an option!)

At least have it as an option for people with modern computers and plenty of RAM.
(That way you don't have to use it, if you don't want to or need to)

I'm not sure it's a good idea for XMPlay to cache files. Windows already uses free memory to cache files, so it's likely to be a waste of memory if XMPlay does that too, ie. 2 copies of the file in memory.

It sounds like what you really want is for the reading to be done as quickly as possible, ie. have it read ahead. That should already happen with MP3 files, as XMPlay scans the entire file to get its length (unless "NoScanMP3=1" is set), but here's an update with an option to do similar with other formats too...

   www.un4seen.com/stuff/xmplay.exe

Enable it by adding a "ReadAhead=<limit>" line to the XMPLAY.INI file (under "[XMPlay]"), where "<limit>" is the maximum file size (in MB) to read ahead for.

Recently I wanted to save a few lists for re-use at a later time. It wasn't that complicated but maybe it can be easier?

After the search history menu was implemented I thought : why not enhance the accessibility to recent playlists as well? Right clicking on the "save lists" button could bring up the last saved playlists and offer a quick load .

That sounds like a decent idea, a sort of simple multiple playlist system. The update above adds a right-click menu to the "Save list" button.

[amit]

That sounds like a decent idea, a sort of simple multiple playlist system. The update above adds a right-click menu to the "Save list" button.

There could be a just single list and the different mouse buttons would determine the action : Left=open list , right=save (also possible simply to left click the button and choose the list name).

If you mention a simple multiple playlist system:doesn't xmplay curently auto saves the playlist every few minutes? If xmplay would treat any loaded playlist as its native and auto update its changes this will result in a true multiple playlist system.  right?

[Ian @ un4seen]

There could be a just single list and the different mouse buttons would determine the action : Left=open list , right=save (also possible simply to left click the button and choose the list name).

Do you mean left/right-clicking on the menu option would determine whether the list is loaded or saved? I think that would be prone to mishaps, eg. accidentally overwriting a list when loading was wanted.

If you mention a simple multiple playlist system:doesn't xmplay curently auto saves the playlist every few minutes? If xmplay would treat any loaded playlist as its native and auto update its changes this will result in a true multiple playlist system.  right?

I did say "sort of"

I don't think that (overwriting the last loaded playlist) could be applied in general, it would need to be optional. For example, the user may have loaded a playlist that they created for an artist/album/etc, and they wouldn't want other stuff that they subsequently played to be automatically added to it.

[Jimmy Neutron]

Enable it by adding a "ReadAhead=<limit>" line to the XMPLAY.INI file (under "[XMPlay]"), where "<limit>" is the maximum file size (in MB) to read ahead for.

What is the default ReadAhead=?

[moriez]

Not sure if this has been suggested or if it's already possible. I go to ''Options and stuff'' quite a lot and have a hotkey set for it. Pressing that same hotkey does not close this menu and makes me have to use the mouse. I like comfort so if possible.. 

[Jimmy Neutron]

It sounds like what you really want is for the reading to be done as quickly as possible, ie. have it read ahead. That should already happen with MP3 files, as XMPlay scans the entire file to get its length (unless "NoMP3Scan=1" is set), but here's an update with an option to do similar with other formats too...

Shouldn't that be "NoScanMP3" ?

[Chinese Sausage]

This has been suggested before but here goes... XMPlay needs an option for full file buffer (ala Foobar2K).

I know this isn't added to keep the memory usage low, which is all well and good. But what about people with memory to burn?

I don't do much on my computer except listening to 20-50megs files. Using XMPlay, the hard disk never stops spinning! I mean never! (Yes, my HD is suppose to stop after 3 mins). It gets noisy and waste power.

Currently I'm using Foobar2K which does allow full file buffer (allowing HD to spin down), that's the only reason I use it. But I really would like to switch back to simplier & smaller XMPlay. (WinAmp is not an option!)

At least have it as an option for people with modern computers and plenty of RAM.
(That way you don't have to use it, if you don't want to or need to)

I'm not sure it's a good idea for XMPlay to cache files. Windows already uses free memory to cache files, so it's likely to be a waste of memory if XMPlay does that too, ie. 2 copies of the file in memory.

It sounds like what you really want is for the reading to be done as quickly as possible, ie. have it read ahead. That should already happen with MP3 files, as XMPlay scans the entire file to get its length (unless "NoMP3Scan=1" is set), but here's an update with an option to do similar with other formats too...

   www.un4seen.com/stuff/xmplay.exe

Enable it by adding a "ReadAhead=<limit>" line to the XMPLAY.INI file (under "[XMPlay]"), where "<limit>" is the maximum file size (in MB) to read ahead for.

It seems after this update that XMPlay starts a little bit faster, at least on my old system.

[Pike84]

Heyy, I noticed the same! Notable improvement

[Ian @ un4seen]

Enable it by adding a "ReadAhead=<limit>" line to the XMPLAY.INI file (under "[XMPlay]"), where "<limit>" is the maximum file size (in MB) to read ahead for.

What is the default ReadAhead=?

The default is 0 (disabled).

Not sure if this has been suggested or if it's already possible. I go to ''Options and stuff'' quite a lot and have a hotkey set for it. Pressing that same hotkey does not close this menu and makes me have to use the mouse. I like comfort so if possible.. 

The "Esc" key can be used to close the Options window.

It sounds like what you really want is for the reading to be done as quickly as possible, ie. have it read ahead. That should already happen with MP3 files, as XMPlay scans the entire file to get its length (unless "NoMP3Scan=1" is set), but here's an update with an option to do similar with other formats too...

Shouldn't that be "NoScanMP3" ?

Oops, you're right. I've corrected that now.

It seems after this update that XMPlay starts a little bit faster, at least on my old system.

The "ReadAhead" stuff shouldn't really affect XMPlay's start time, but rather just result in audio files being read from disk as quickly as possible

[Pike84]

The "ReadAhead" stuff shouldn't really affect XMPlay's start time, but rather just result in audio files being read from disk as quickly as possible

I would have thought so too, but XMPlay really did start faster after I downloaded the latest "stuff".

Actually, I might have an idea why, without any changes in XMPlay itself though: I normally run it quite soon after booting the machine, and probably some Windows processes haven't fully loaded in most of the instances, thus slowing others down too.

How disappointing .

[edit]Hmm... Just now I booted my machine and started XMPlay early, along with a couple of browsers and the basic stuff, and it still seemed to come up faster. Are you sure there's nothing in the new version that might affect the start up time? I'm not complaining .

[amit]

On the "Load" menu  of previous playlists maybe right click can add playlists instead of replace , maybe middle click can queue them?

I did say "sort of"

yes , you did

Creating a multiple playlists system is basically the same thing as having previous lists accessed easily and saving them automatically. Thinking about it again though , I don't think it would be wise to have it confused with regular saved lists.

This should be on another dedicated button (queue/list or completely new button) offering to add a new "playling now/virtual list". A regular pls playlist will be saved in xmplay data folder and be updated regularly as if it was the default. A list of these playlists will be available on right click of that button thus  making switching between them a breeze .

[Ian @ un4seen]

[edit]Hmm... Just now I booted my machine and started XMPlay early, along with a couple of browsers and the basic stuff, and it still seemed to come up faster. Are you sure there's nothing in the new version that might affect the start up time? I'm not complaining .

I can't see anything recent that would affect start up time. Have you removed (or updated) any plugins recently, or removed other files from XMPlay's directory, or removed a load of entries from the playlist/library? Or perhaps you've just changed skin? Different skins will have differing load times, although probably nothing too noticeable.

On the "Load" menu  of previous playlists maybe right click can add playlists instead of replace , maybe middle click can queue them?

I'm actually not sure that the Windows menu functions are able to inform which mouse button was clicked. They don't appear to be.

Regarding queueing/adding, when the playlist is in queue display mode, the loaded playlist will just replace the queue and get added to the playlist (rather than replacing it) in the process.

[Pike84]

I can't see anything recent that would affect start up time. Have you removed (or updated) any plugins recently, or removed other files from XMPlay's directory, or removed a load of entries from the playlist/library? Or perhaps you've just changed skin? Different skins will have differing load times, although probably nothing too noticeable.

Ok, well I haven't added or removed any plugins or the skin, but I have made changes in the playlist, and it's changing a little all the time.

However, I've been thinking that it might rather be related to my HD's peculiarities. With the one that I'm running XMPlay from, it occasionally takes some time just to open the folder view in resource manager. Also, last time I ran XMPlay, it started a little slower again, so it probably hasn't anything to do with its code.

[ChemZ]

Nice work with the ReadAhead! Hard disk actually sleeps now

Also noticed the memory usage hasn't risen, seems exactly the same as before

Loading a 40meg file:
- foobar2k (full file buffer): ~58,000K
- XMPlay (ReadAhead): ~3,000K

Loading a 40meg file, then minimize player:
- foobar2k (full file buffer): ~8,000K (but then rises by ~500K every second)
- XMPlay (ReadAhead): ~1,500K to 2,500K (stable)

Great job!

ReadAhead - For non-mp3 files, maximum file size (in MB) of read-ahead buffer (default: ReadAhead=0)

Does that mean ReadAhead doesn't work for mp3 files? Seems to work for me... 

[Pike84]

No, it means that it's not needed for mp3 files, since they are fully read by default .