INTERACT FORUM
More => Old Versions => JRiver Media Center 24 for Windows => Topic started by: RD James on March 19, 2018, 11:55:52 pm
-
As always: with a new version of Media Center, I'd like to see Memory Playback improved.
An ideal memory playback system would:
- Protect against interruption from slow/unreliable disk/network connections.
- Be memory efficient, using as little as is necessary for the job.
- Be fast. Playback should start as quickly as possible.
- Play nice. It should not interfere with the operation of other programs on the computer.
None of the current options tick all the boxes.
- Load full file (not decoded) into memory: It's fast, and it uses very little memory. But gapless playback can break with slow/busy disk/network connections, or external drives that may go to sleep. These gaps can be long, depending on the access speed (I've had it take minutes before). Has the least impact on other applications.
- Load decoded file into memory: It's fast, but memory inefficient. You get a burst of CPU usage at the start of every track, which can interfere with other programs on the system if playing demanding formats like multichannel DSD. It has the same gapless issues as above.
- Load full album (not decoded) into memory: It's very slow and memory inefficient. It has to load all ~30 tracks into memory before playback begins. It can leave very little memory free for other applications on the system. If there are too many tracks or the tracks use too much memory, it falls back to streaming directly from the disk which is a bad failure state. It does fix the gapless problem, however.
One thing in the "load decoded file into memory" option's favor is that it does work with SACD ISO.
It's still an inefficient use of memory, but the other two options play SACD ISO directly from disk.
So what's the answer?
Well, I'd like to see one Memory Playback option that covers all bases.
1. Load a single non-decoded track into memory and start playback.
2. Queue at least two upcoming tracks in a buffer once playback begins.
3. Every time one track finishes, load a new track into the buffer.
- Since multiple tracks are queued in advance, it protects against sleeping/slow/unreliable disk/network connections. Playback should always be gapless (if desired).
- As it is loading non-decoded tracks into memory, and only buffering a small number of upcoming tracks, it is memory efficient.
- Playback would start when the first track is loaded in memory rather than waiting for the entire queue to be full, making it fast.
- Since it does not decode the tracks into memory, or load entire albums/playlists into memory, its CPU and memory footprint should have minimal impact on other programs running at the same time.
There are two potential flaws I can see with this setup:
1. If you only queue two tracks in advance (a total of three tracks in memory) it does not guarantee the length of the buffer will be sufficient.
Some albums may have one or two very short tracks in-between regular tracks, or you may want to skip a track or two, which means that you could still run into playback issues with very slow disk access.
A solution for that would be to start with 2 tracks and add more until the buffer is over a certain duration. 8 minutes should only queue 2-3 tracks unless they are very short, keeping the memory footprint low.
2. It doesn't cover SACD ISO. I don't know if there's a way that you could buffer tracks from SACD ISO without either decoding them into memory (inefficient and doesn't 'play nice'), or loading the entire ISO into memory (very inefficient use of memory).
Perhaps that is a lost cause, and they would have to be split to separate DFF/DSF tracks.
This gets us back to a single on/off preference for Memory Playback, rather than having to explain the differences and pick one.
I suppose if you really wanted to cover everything, you could have a "decode current track into memory" option to cover SACD ISO playback, and 'audiophiles' that believe it improves the sound quality. Upcoming tracks would be stored in a non-decoded state.
-
I also would like optimizations to this. As far as I know, memory playback crashes when there is not sufficient memory available anymore: https://yabb.jriver.com/interact/index.php/topic,112686.0.html
-
I would add also playback of video files
I have 16GB of RAM
-
I would add also playback of video files
I have 16GB of RAM
I too would like to see support of memory playback of video files .
-
For mp4 files ~2 GB for 90 min movie playback in memory playback could be feasible? -but not for a 40 GB blu-ray rip. For me the current version is of video playback works 100%.
-
A feature like this would greatly improve the audio experience and could encourage many people to upgrade. Let's keep this thread about audio. Please enter a new topic for video playback from memory.