More > JRiver Media Center 19 for Windows
NEW: Improved memory playback
6233638:
--- Quote from: jtwrace on September 05, 2013, 09:25:36 pm ---Will this memory play affect us NAS users any? I know now that it's recommended that we do not use memory play. So will this change for us?
--- End quote ---
There are good and bad things that happen when you enable memory playback over a network.
Good: if the track can be fully cached in memory, network traffic is no longer going to affect seeking or potentially interrupt playback.
Unfortunately MC19's memory playback option does not guarantee that the entire track will be cached.
Bad: When you enable memory playback, all the network traffic is at the beginning of the track, so you might then have 3-5 minutes (or longer) without any network traffic.
When it comes to playing the next track, the network might be slow to respond and introduce a delay between tracks, breaking gapless playback. (depends on your network)
With memory playback disabled, it's continually streaming data over the network, so the connection should still be open and gapless playback should be more likely to keep working.
I have to imagine that having memory playback enabled creates a big spike of traffic whereas disabling it means you just have a continuous low-level amount of traffic. This may or may not cause problems for other devices on your network. (probably not though?)
And once again, this would be improved if memory playback was reverted to the MC18 style where it caches the file and not decoded audio, as this guarantees that the entire track is cached in memory 99% of the time. Many times MC19 only caches part of the track that is currently being played.
If you switched to MC18-style caching, while allowing it to use up to 1GB, you could cache the current and next tracks in RAM, eliminating the gapless playback issue because you have the full duration of the current track to get the next track into memory.
jtwrace:
Thanks for the explanation.
If I'm reading the correctly though, MC18 has better memory playback (which can't be the case).
--- Quote from: 6233638 on September 06, 2013, 03:00:06 am ---
And once again, this would be improved if memory playback was reverted to the MC18 style where it caches the file and not decoded audio, as this guarantees that the entire track is cached in memory 99% of the time. Many times MC19 only caches part of the track that is currently being played.
If you switched to MC18-style caching, while allowing it to use up to 1GB, you could cache the current and next tracks in RAM, eliminating the gapless playback issue because you have the full duration of the current track to get the next track into memory.
--- End quote ---
rayooo:
--- Quote from: jtwrace on September 06, 2013, 08:16:00 am ---Thanks for the explanation.
If I'm reading the correctly though, MC18 has better memory playback (which can't be the case).
--- End quote ---
depends on what your definition of "better" is.
sound quality: if you are in the "Objectivist" camp, sound quality will be identical in 18 and 19.
if you are in the Subjectivist camp, then surely there will be 10 opinions for every 5 people. These opinions will cover any and all possible combinations of better/worse/the same sound quality.
from a usability point of view:
Mem Play in MC18 more usable with wider range of formats and use cases. 19 could as mentioned have usability issues.
While I personally fall into the Objectivist group, I like options, thus I'd like to have both the 18 and 19 Memory Play options available.
6233638:
--- Quote from: jtwrace on September 06, 2013, 08:16:00 am ---Thanks for the explanation.
If I'm reading the correctly though, MC18 has better memory playback (which can't be the case)
--- End quote ---
MC19 audio playback is "better" from an audiophile perspective because it caches decoded audio rather than compressed audio. It was a commonly requested feature.
MC18 cached compressed audio (the file) with a small (roughly 40MB) buffer for decoded audio.
I don't hear any benefit from caching decoded audio instead of compressed audio (and I think the JRiver team would agree...) so MC18 does have better memory playback as far as I am concerned - and a small tweak (caching the next track, in addition to the current track) would use less memory than MC19, and have more stable playback.
I've never run into CPU usage impacting audio playback in MC18, in MC19 both CPU usage and disk I/O can interrupt playback with the new method of memory playback.
I have no problem with people wanting to cache decoded audio (even though I don't see the need) but I'd like the option to switch back to an MC18 style of memory playback which kept CPU usage lower and was mostly immune to disk/network access.
jtwrace:
Thanks for clarification. So does that mean that MC19 has both (MC18 & MC19) memory play?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version