INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: Matt on July 15, 2013, 11:45:13 am
-
Overview
Memory playback now holds decoded data in memory instead of encoded data.
This means playing any form of lossless (WAV, FLAC, APE, ALAC, etc.) will have identical data in memory and identical resource usage.
Benefits
The theoretical benefits of memory playback are that no disk or network I/O occurs while playing and that CPU load during playback could be reduced.
Technical Considerations
With a modern computer, playback of a standard CD-quality file will have the fully decoded file in memory in around one second.
Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage).
In some cases, the work of decoding and caching a file quickly as a track starts could lead to other problems. For example, when playing over Wi-Fi some machines exhibit high resource usage when reading a file quickly. This resource usage as a track starts could lead to audio playback glitches.
Some files like DSD played as PCM have very large decoded data so that they might require more memory to cache than (most) any system has. In these cases, the program will cache 1GB, play it mostly out, then cache another 1GB, etc.
With memory playback enabled, the player will no longer report a real-time bitrate (ie. 872 kbps) during playback. This is because asking the decoder its current bitrate is not possible when the decoder has finished with the current track completely in the first couple seconds of playback.
Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback.
The option was added due to popular demand.
How to Use
You enable or disable memory playback in Options > Audio > Play files from memory instead of disk.
It is off by default.
-
Nice. I will keep this option off. Hopefully, this will either bust a few myths or let people hear the difference they've been wanting. Win-win.
-
The decoding seems to be almost instantaneous on my PC. This feature will also allow people to see how fast decoding really happens.
-
Fantastic!!!! thanks. ;D
-
Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage).
Nice to see JRiver having true memory playback
I wonder why you put a hardcoded constrain on it.
Can imagine that a user run Win64 with 8 GB could use a higher value.
Why not making it a user configurable parameter?
-
Overview
Memory playback now holds decoded data in memory instead of encoded data.
This means playing any form of lossless (WAV, FLAC, APE, ALAC, etc.) will have identical data in memory and identical resource usage.
Benefits
The theoretical benefits of memory playback are that no disk or network I/O occurs while playing and that CPU load during playback could be reduced.
Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage
Some files like DSD played as PCM have very large decoded data so that they might require more memory to cache than (most) any system has. In these cases, the program will cache 1GB, play it mostly out, then cache another 1GB, etc.
With memory playback enabled, the player will no longer report a real-time bitrate (ie. 872 kbps) during playback. This is because asking the decoder its current bitrate is not possible when the decoder has finished with the current track completely in the first couple seconds of playback.
Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback.
The option was added due to popular demand.
How to Use
You enable or disable memory playback in Options > Audio > Play files from memory instead of disk.
It is off by default.
So 1 GB is the most that would be in memory regardless of how muck memory I have? If so adding a large amount of memory like 16GB or 32GB would offer no improved capability beyond the 1GB?
-
So 1 GB is the most that would be in memory regardless of how muck memory I have? If so adding a large amount of memory like 16GB or 32GB would offer no improved capability beyond the 1GB?
MC is a 32-bit application and as such its total memory usage is limited, it would never be able to use this much memory.
-
Nice to see JRiver having true memory playback
It already did have "true" memory playback, playing from a buffer of decoded audio. But it now buffers 1GB which will allow most(?) tracks to be fully decoded into memory.
Can imagine that a user run Win64 with 8 GB could use a higher value.
If I recall correctly, a 32-bit application should be able to use ~3GB on a 32-bit OS and ~4GB on a 64-bit OS.
Moving to 64-bit would likely add a number of issues and incompatibilities. (e.g. no high quality video playback, lower compatibility with VST plugins)
Why not making it a user configurable parameter?
I agree, it would be nice if this were user configurable.
-
It already did have "true" memory playback
Are you sure? See Matt's opening post, the decoding before playback started is one of the new features IMHO
-
Are you sure? See Matt's opening post, the decoding before playback started is one of the new features IMHO
Agreed..that's what I thought as well... The "old" play from memory cached the raw disk data in ram, then, decoding, resampling etc. was performed during playback.
The new play from memory does all decoding, DSP operations etc, caches this result in ram .. And then begins playback. Do I have this roughly correct???
-
Both MC18 and MC19 have true memory playback in that there's no disk I/O during playback.
MC19 moves decoding to the front side instead of doing it on the fly. This moves about 1 or 2 seconds of CPU time spent decoding to the start of playback instead of spreading it smoothly over the course of a song. This means all forms of lossless are completely identical in memory and with regards to resource usage during playback.
-
This means all forms of lossless are completely identical in memory and with regards to resource usage during playback.
Anybody still hearing a difference is need of tweaking his placebo a bit better ;D
-
Oops - missed the word "still", so never mind. :)
-
If I recall correctly, a 32-bit application should be able to use ~3GB on a 32-bit OS and ~4GB on a 64-bit OS.
Under normal circumstances, a 32-bit program on 32-bit OS can allocate 2GB of RAM. The remaining 2GB is allocated for the OS. Unless the hardware doesn't support relocating hardware addresses to above 4GB barrier, then the user space gets less, usually between 256MB and 768MB less. Its also possible to configure the OS to use 1GB instead of 2, and the user space gets that 1GB extra. This is not something that's automatic or enabled by default, it requires the user to set "increaseuserva" parameter via bcdedit on Vista and above, or /3GB switch on XP. Limiting the OS to 1GB can also lead to problems although I admit its not very common, problems mostly arise on terminal servers/citrix environments.
On a 64-bit OS a 32-bit program should in theory be able to allocate the full 4GB of RAM that 32-bit can allocate (2^32).
Note the "in theory", because I have no idea if it requires major changes in code and whether that breaks true 32-bit compatibility for instance.
-
Anybody still hearing a difference is need of tweaking his placebo a bit better ;D
;D Anyone hearing a difference before also needed said tweaking!
-
Overview
Memory playback now holds decoded data in memory instead of encoded data.
This means playing any form of lossless (WAV, FLAC, APE, ALAC, etc.) will have identical data in memory and identical resource usage.
Benefits
The theoretical benefits of memory playback are that no disk or network I/O occurs while playing and that CPU load during playback could be reduced.
Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback.
The option was added due to popular demand.
Thanks much.
This feature should make a lot of customers happy and end a lot of debates.
-
On the two computers I've had since I started using J River, memory playback has only had a negative effect on SQ in my ears. I have frequently tested it but have always ended up leaving that particular box unticked. But it will be interesting to see (hear) if the new implementation improves things. I definitely prefer Pure Music on the mac in memory playback mode and I believe that player decodes the audio files before putting them in memory. Same with Audirvana which is also a very good sounding audio player for the mac.
Either way, I'm really happy with the way MC 18 sounds without using memory playback so I won't be very disappointed if the new implementation of memory playback doesn't add anything. And I use wav with MC anyway, so the theoretical advantages compared to the old implementation should be even less noticeable.
Anyway; thanks for continuing to develop this great piece of software. I'm happy to continue my support by upgrading to 19.
-
this is fantastic!
-
Can we have JRiver that is 64 bit??
And choose the MAX size of the memory use for songs? I have DSD files of 128DSD or 24/192 files of FLAC and such, I want them to be fully decoded in the memory, even it use 2GB of memory or more!
I have 16GB of memory and no problems of upgrading it to 32GB, so no issues here, so?
Can it be done?
That will be great!
-
Can we have JRiver that is 64 bit??
Last time it came up, 64-bit was not planned yet. Maybe in a future version, but i would not expect it for MC19.
-
Last time it came up, 64-bit was not planned yet. Maybe in a future version, but i would not expect it for MC19.
Why is that?! isn't it about time to have both 32 bit and 64bit versions??
-
Probably because moving to 64-bit breaks compatibility with a lot of plugins - including madVR - and because there's no audible benefit to using memory playback.
-
and because there's no audible benefit to using memory playback.
Just my 2 cents, I was involved in a group ABX testing, which totally backed up what 623 is saying so I never bothered with it anyways (no debate, everybody has a choice of course).
However, I decided to try it on a client playing music remotely on a PC, and although no noticeable audio improvement as expected, but I thought it made my network connection faster ... is this possible or is this a placebo effect, I don't know. Seems obvious when searching within a song. But I also noticed an increase of speed before -- maybe it has more to do with the dev's work to increase this in the last couple of months/versions
Btw, Server is still configured without memory playback and sounds great on my stereo, so I don't see why I would change that.
-
However, I decided to try it on a client playing music remotely on a PC, and although no noticeable audio improvement as expected, but I thought it made my network connection faster ... is this possible or is this a placebo effect, I don't know. Seems obvious when searching within a song. But I also noticed an increase of speed before -- maybe it has more to do with the dev's work to increase this in the last couple of months/versions
The way that memory playback works in MC18 is that it caches the entire file in memory, and then has a buffer of ~40MB for decoded audio during playback.
This means that when you seek through the file, it will be accessing it directly in memory, rather than relying on network access, which explains why it would be faster to seek through a track.
The downside to using memory playback over a network is that you may have a slight delay during track changes if your network is slow to respond, because all the network activity happens at the start of a track.
If you are streaming the track (memory playback disabled) then the connection is in use throughout playback, and should still be "open" when the track changes, so you may have less delay.
Media Center 19 has made a number of changes to the way that memory playback works, that satisfy the audiophile requests for "real" memory playback, but I think it negatively impacts performance in a number of ways, for no audible benefit, and it's now possible for a track to only be partially cached if it exceeds the ~1GB buffer when decoded.
-
thanks for the info 623 :)
-
Warning - some of you will want to close your eyes....
There was an extensive blind test that showed audibility.
Okay, it is now safe to go back to your abstract fantasy world where everything is the way it ought to be, and everything can be measured.
-
Warning - some of you will want to close your eyes....
There was an extensive blind test that showed audibility.
Okay, it is now safe to go back to your abstract fantasy world where everything is the way it ought to be, and everything can be measured.
+1
I'm happy 'Improved memory playback,' among other features mentioned, is incorporated in MC19. Upgraded already - looking forward to its release...
-
Glad to hear that! When I first used MC 19 today, I noticed an small improvement in sound quality and wondered if it was just my imagination. 8)
-
Knock-on-wood the new mem play works wonderfully on my desktop. very little delay.
Random track changes to 44k (Flac) are virtually instant play. 88k and up takes maybe 1/4 to 1/2 second tops. no muss, no fuss.
(connection is via wired Gig-E to Synology NAS)
Oh and it sounds wonderful also. ::) :P 8) :o ;D
Having said the above, guarantees I'll have trouble when I put 19 on the main player. :'(
-
Is no-one else having problems with the new memory playback—particularly with DSD?
I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.
It also uses 2–4x the RAM for no benefit. It's a major issue.
Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?
-
Is no-one else having problems with the new memory playback—particularly with DSD?
I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.
It also uses 2–4x the RAM for no benefit. It's a major issue.
Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?
I don't have DSD (yet) all PCM/WAV currently. My main player is dedicated to audio, desktop is multi purpose with SPDIF output to cheapo DAC. It's a multi use machine..but 16Gig RAM and way over powered for the need.
near as I can tell simply using Windows Resource Monitor... during track change, network usage goes from virtually zero up to approx 90Mbit/Sec and 10% utilization for a brief time. CPU usage goes from 1% up to approx 4%, again, very briefly.
Only other tasks going on are Email (Outlook) and Browser (Firefox)
I'll check this info again on the main player (dedicated listening room player) and see what it shows.
...PS I need to get a DSD Dac to play with.
-
DSD files are very big. Loading from a slow drive or a network drive would be noticeable.
-
Is no-one else having problems with the new memory playback—particularly with DSD?
I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.
It also uses 2–4x the RAM for no benefit. It's a major issue.
Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?
I have one album in dff, SRV& DT, Couldn't stand the weather, so I figured I'd give it a swing. 2nd track loads 1,3GB in memory. It plays instantly and skipping is instant. I actually had to check memory playback was enabled because I expected at least some delay.
Edit: I'll recheck later, cpu is at 100% because analyze is running minimized. :-[
-
DSD files are very big. Loading from a slow drive or a network drive would be noticeable.
They're loading off a 4TB WDSE (http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-771475.pdf) which is one of the faster hard drives around. (171MB/s)
The problem is that memory playback no longer caches the file it's playing in memory - it relies on disk/network access when decoded audio exceeds the 1GB buffer (common with DSD files) and DSD files require much more CPU than PCM to decode.
Because it's trying to fill 1GB of decoded audio as quickly as possible, you have maybe 20 seconds of 100% CPU usage (on a fast system - 5000 JRmark score) every time there's a track change or seeking occurs, and there's maybe 5-10s of silence as it buffers.
If I'm doing anything else on the computer, this prolonged CPU usage every time there's a track change interferes with whatever else I was using the system for.
In MC18 which cached the files in memory and used a ~40MB buffer, seeking was instant, CPU usage was about 20% at most (typically <1%) and I never had Media Center tell me that it was "buffering" during playback.
The largest single track I have is ~500MB (20 minute multichannel DSD file) which meant that MC18 had half the memory footprint of MC19. (typically much lower)
This seems like a serious regression in performance and usability just to tick off an audiophile checkbox.
The seeking issues would be solved if Media Center had a larger buffer that allowed the entire file to be decoded into memory (which probably requires a 64-bit build and more than the 8GB RAM I have) but that would then make the high CPU and memory usage even worse. As I understood it, JRiver's position was that memory playback should not have any impact on audio quality, so that seems like it would be heading in the wrong direction.
The best solution seems like it would be to make the size of the decoded audio buffer adjustable (so I can reduce it back down to ~40MB or whatever MC18 used, rather than 1GB) and to bring back the option of caching the file so that disk/network access is not a factor. The logical extension of that seemed like it would be to allow caching multiple files at once—even just two—so that disk access can never impact playback. (currently Media Center only starts loading the next file in the last ~10s of a track) Even with two tracks cached (the current and next one) memory usage would be lower than it is now.
PS I need to get a DSD Dac to play with.
I'm actually converting to PCM to take advantage of Volume Leveling.
-
Because it's trying to fill 1GB of decoded audio as quickly as possible, you have maybe 20 seconds of 100% CPU usage (on a fast system - 5000 JRmark score) every time there's a track change or seeking occurs, and there's maybe 5-10s of silence as it buffers.
I have 312 dsf files on an external USB hard drive. With memory playback, the files play instantly, seeking is instant, and changes to the next track are instantaneous. I have a 32-bit Windows 7 computer (3707 JMarks) with 3 GB of memory. JRiver only uses about ~600 MB even if I'm showing 2 Gb available. My CPU goes to 14% for two seconds before dropping back to 0, but playback is instantaneous.
I played my largest track (720 MB) and smallest track (77 MB) with no problems.
-
I have 312 dsf files on an external USB hard drive. With memory playback, the files play instantly, seeking is instant, and changes to the next track are instantaneous. I have a 32-bit Windows 7 computer (3707 JMarks) with 3 GB of memory. JRiver only uses about ~600 MB even if I'm showing 2 Gb available. My CPU goes to 14% for two seconds before dropping back to 0, but playback is instantaneous.
Are you bitstreaming, or converting to PCM? Are the files DST compressed? It's usually more problematic when downmixing from multichannel as well.
EDIT: I just realized that if they are DSF files, they will be uncompressed stereo tracks.
After checking this, it seems like the problem may only be with DST compressed tracks. (DSF is uncompressed, DST compression is optional with DFF stereo tracks)
What may also make a difference is that I have Media Center set to use the minimum ASIO buffer size (so seeking etc. should be instantaneous)
-
I am converting to PCM. Using ASIO with JRiver buffers set to "Minimum Hardware Size" works just fine.
It sounds like maybe DST compressed files will need to be handled differently.
-
It also uses 2–4x the RAM for no benefit. It's a major issue.
If you don't receive a benefit, why not turn off the feature ??
-
If you don't receive a benefit, why not turn off the feature ??
Well in MC18 it meant that seeking was instant and disk I/O wouldn't affect playback.
-
If dsf isn't a problem you could consider converting them maybe?
-
If dsf isn't a problem you could consider converting them maybe?
Are there any tools to convert DFF to DSF? I could always re-rip, but anyone that's done that before, knows why I am reluctant to do so.
DSF files are limited to 2 channels, and DST compression saves you 50% space - which is a huge amount. (uncompressed DSD is much larger than anything else)
If anything, I'd rather be converting all my rips to DFF files with DST compression, and discarding the stereo tracks when there's a multichannel one available - but right now multichannel doesn't level properly when downmixed, and I don't have the option of bitstreaming that.
It just seems like Media Center has gone from being this nice efficient player, to wasting a gig of RAM for seemingly no benefit, and a number of performance regressions.
I don't even have to be doing anything complex on my system for the new memory playback to have an impact - if I'm playing anything using DST compression and scrolling a web page, it starts skipping every time there's a track change.
As I mentioned above, it seems like a better use of that RAM would be to cache the currently playing and next track in memory, instead of this huge buffer of decoded audio.
-
I'm afraid I can't really help you with that. I've played with SACD ISO's and I thought it was too much work and I didn't have time to read up on it. I still have the ISO's on disk, but for most of them I got the regular CD's ripped to Flac.
So while I admit I don't know anything about it and I'm probably not very helpful ::), but isn't it an option to convert sacd iso's with MC19 to DSD? I tried one track and the result is a dsf file which seems to be the same as as the bunch of dff files I have.
-
I'm afraid I can't really help you with that. I've played with SACD ISO's and I thought it was too much work and I didn't have time to read up on it. I still have the ISO's on disk, but for most of them I got the regular CD's ripped to Flac.
It's easy enough to go from SACD ISO to either DSF or DFF (sacd_extract will do it) but I don't know how to perform the conversion from one format to the other after that. If the tracks are uncompressed, I have already converted them to DSF (I prefer individual tracks to an ISO) but if they are compressed, I keep them as DFF files. Multichannel discs require the use of compression, and most stereo discs are uncompressed. It makes sense that they would be uncompressed just to fill out the disc, but it's a pain when you are trying to rip a collection and have to store the files.
So while I admit I don't know anything about it and I'm probably not very helpful ::), but isn't it an option to convert sacd iso's with MC19 to DSD? I tried one track and the result is a dsf file which seems to be the same as as the bunch of dff files I have.
As I understand it, Media Center's DSD conversion converts to PCM and then encodes to a DSD file. So you effectively double the noise on each track. (or try and filter out the noise, and add it back)
I don't see converting files and doubling their size on disk as a solution though - Media Center 18 had no problem with these files.
And even after conversion, they're still not going to fit into that 1GB buffer.
-
So are you saying that the reason you don't want to just turn it off, is that you like the MC18 memory playback "that has no benefit", but not the MC19 memory playback "that has no benefit" ?
And by the way, real-time decompression of multi-channel SACDs is unquestionably the most CPU-intensive audio playback task. Before Matt added the multi-threading, I had difficulty doing it at all with marginal PCs.
Lastly, SACDs that have multi-channel tracks and stereo tracks, often have different audio from different sources on the stereo track. Sometimes, that means the stereo tracks have value. Sometimes the multichannel tracks have been done better, sometimes the stereo tracks. I like multichannel audio, but those tracks are not automatically better just because they are multichannel. It varies from release to release, there are no reliable patterns.
-
So are you saying that the reason you don't want to just turn it off, is that you like the MC18 memory playback "that has no benefit", but not the MC19 memory playback "that has no benefit" ?
No audible benefit. MC18/19 sound the same whether memory playback is enabled in them or not.
In MC18 when you enable memory playback, seeking is instant with all files (as the entire file is cached in RAM) and disk/network I/O cannot interrupt playback. (e.g. multiple file copy operations running in another program) CPU usage is low, because Media Center is only trying to fill a ~40MB buffer.
In MC19 seeking is instant once the track has been decoded if it fits into the 1GB cache - but memory usage is much higher as it caches decoded audio rather than the compressed file.
When the decoded audio does not fit into memory (common with DSD) disk/network I/O can impact playback or seeking performance. CPU usage is very high when tracks change or you seek, because it's now trying to fill a 1GB buffer instead of 40MB.
In MC18 I bet you could play a track over your network, pull the plug, and it would play to the end. In MC19 the track might stop halfway through. (assuming it's a large DSD file)
I think MC18's memory playback was a much better design than we have now, and the only improvement it needed would be to cache both the current and next track, instead of only the current track - that gives you 3+ minutes to grab the next file, instead of ~10s.
In theory, MC19's memory playback feature could make playback less susceptible to interruption due to high CPU usage, but that has never been a concern for me, and the high CPU usage inside MC19 now interferes with other programs running on the system.
And by the way, real-time decompression of multi-channel SACDs is unquestionably the most CPU-intensive audio playback task. Before Matt added the multi-threading, I had difficulty doing it at all with marginal PCs.
I have an i5 2500K running at 4.5GHz - it should not be an issue.
Lastly, SACDs that have multi-channel tracks and stereo tracks, often have different audio from different sources on the stereo track. Sometimes, that means the stereo tracks have value. Sometimes the multichannel tracks have been done better, sometimes the stereo tracks. I like multichannel audio, but those tracks are not automatically better just because they are multichannel. It varies from release to release, there are no reliable patterns.
Well that's part of the reason I've kept both so far. I still prefer converting to DSF/DFF files than SACD ISO though, as it means I can tag them properly. (and the metadata is stored in them with DSF files)
-
Immensely happy with the improved audio memory playback, and the other additional audio features in JR 19. Has benefited my setup greatly!! JRiver 19 upgrade purchase is a no-brainer.
-
I have posted about this feature on an audiophile-friendly forum, and I think it should improve JRiver's reputation in those circles...
-
Thanks a lot for this change, it does sound better on my system - not placebo! (hopefully)
-
I've now installed MC19 on a second system, my primary (music room) player, and once again, I'm amazed how well the new-style play from memory works.
Quite honestly, I see no downside whatsoever.
As a test, I have a 24/192 version of Yes/Tales from Topographic oceans. The longest track on that album is 21:38 and it's around 800MB in size on disk. (FLAC)
When loaded and playing, I see the MC19 memory usage increase by approx a full GB. (playing smaller sized files, the memory usage seems to track as one would expect...I guess)
What I'm having a hard time understanding is, how can this track possibly load and play in a half second.
in effect, "CD" resolution tracks play "instantly"..others take a bit longer.. I just expected this long track would be more noticeable, it's really not.
It's a wired GIG-E to NAS, and it's an i7-4770S CPU, so reasonably fast system, but I'm still a bit confused actually.
-
Playback starts before the full track is loaded into memory. If you're seeing ~1GB of memory usage, the decoded audio is probably too big to fit into the amount of RAM MC19 allocates, as you are at the limit.
FLAC is really quick to decode though - it's only DSD tracks, and particularly DST compressed DSD tracks which seem to require a lot of CPU usage, taking as much as 20-30 seconds to fill the buffer on my system - which renders the computer unusable for ~20 seconds every time the track changes, and does not cache the full track any more, meaning that seeking can be impacted by disk I/O. This did not happen in MC18, because it always cached the entire file.
In practice, I see little difference between MC18 and MC19's behavior when playing CD quality tracks or high res PCM, other than increased memory usage (because it stores decoded audio rather than compressed audio) and a spike of CPU usage at the start of a track as it tries to fill the buffer as quickly as possible.
-
Ah, OK, I didn't understand ? how the new scheme worked.
I thought the entire load/decode/process occurred before any playback began. Assuming of course the track isn't too big to to fit within the 1GB max.
So technically speaking IF one were to believe urban legend, a track that begins playing back, would sound worse during the first seconds that decoding is still progressing... and would magically improve once the full load/decode/process task was finished. (and I'm not at all suggesting I subscribe to this stuff)
-
So technically speaking IF one were to believe urban legend, a track that begins playing back, would sound worse during the first seconds that decoding is still progressing... and would magically improve once the full load/decode/process task was finished. (and I'm not at all suggesting I subscribe to this stuff)
IF that's what one were to believe, he would probably hear it ;).
-
IF that's what one were to believe, he would probably hear it ;).
I'm still trying to hear the difference between setting my DAC at no over-sampling vs 4X oversampling.
On a good day, I "think" I can hear a slight difference.
I'm a long long way off being able to listen to music from a computer and identifying what background tasks are running based on listening to the audio.
-
I'm a long long way off being able to listen to music from a computer and identifying what background tasks are running based on listening to the audio.
If you manage that, you would deserve a place in the Guinness book of records. ;)
-
When loaded and playing, I see the MC18 memory usage increase by approx a full GB. (playing smaller sized files, the memory usage seems to track as one would expect...I guess)
Did you mean MC19 in that sentence ?
-
Did you mean MC19 in that sentence ?
Ah, yes, meant MC19. my mistake, thanks!
-
IF that's what one were to believe, he would probably hear it ;).
And if one is certain that there are no difference, that is what one will hear as well, what one expects.
-
It would seem that since this feature is designed for people who perceive a difference, then further enhancements for those people would be (in order from most desirable):
* - Option for user to specify the amount of RAM available to be used (default to be the current default)
* - Option to have MC19 pause playback at the beginning of the track until the initial decoding is complete (default to be the current default, i.e. no pause)
The latter option would be especially helpful for those who want to do comparison testing.
-
It would seem that since this feature is designed for people who perceive a difference, then further enhancements for those people would be (in order from most desirable):
* - Option for user to specify the amount of RAM available to be used (default to be the current default)
* - Option to have MC19 pause playback at the beginning of the track until the initial decoding is complete (default to be the current default, i.e. no pause)
The latter option would be especially helpful for those who want to do comparison testing.
+1 Agreed!
-
* - Option for user to specify the amount of RAM available to be used (default to be the current default)
Yes, I would really like to reduce the decoded audio cache from ~1GB back to ~40MB like MC18 used to avoid having unacceptably high CPU usage at the start of each track.
I'm sure some people would like to reduce it from 1GB to maybe a few hundred MB, and others would want to push it to 2GB or whatever the limit is as a 32-bit application. (I think 4GB if it's on a 64-bit OS?)
There also needs to be an option to cache the file instead of decoded audio so that disk I/O cannot affect playback, as it can now when decoded audio exceeds 1GB. This is a serious regression.
Personally, the biggest change I would have liked to see from MC18>MC19 as far as memory playback is concerned, would be the option of caching the current and next tracks in RAM, instead of only the currently playing track, to eliminate disk I/O from impacting playback at all.
* - Option to have MC19 pause playback at the beginning of the track until the initial decoding is complete (default to be the current default, i.e. no pause)
This leads to a horrible user experience with potentially 5-20 seconds gaps between each track.
With Media Center being a 32-bit application, it's limited in the amount of RAM it can use, so adding the option to decode the entire playlist before playback (or as much as can fit inside the allocated memory) could potentially have a long wait - and then what do you do if you only have room to cache say 6/30 tracks at a time? Do you play six tracks and pause, or do you start decoding a new track each time one finishes? (which means that you have CPU usage during playback again...)
As far as I can tell, JRiver's position on "bit-perfect" playback has not changed, and bloating the amount of RAM MC19 uses was done for no reason other than placating audiophiles that think they can hear a change.
-
Memory playback works fine for me even with the largest files (2.2GB dff, 2GB Wave, 515MB Flac), within 2-3 seconds MC's memory is up to ~1000MB, playback starts instantly and skipping is also instant when I skip to the end of that song (it should have to reload a part because it doesn't fit).
Having said that, the reason for me to use memory playback is not because it sounds better but because I want to reduce the chance that high disk activity from another process would interfere with MC filling its buffers while a song plays. Without memory playback, I've seen the buffering ... message once or twice and I find that annoying and disruptive when I'm listening to music. This turned out because something else was hogging the harddisk in the background and MC simply didn't get enough time to fill its buffers.
With MC18, this could never happen except during a track switch or when the compressed file wouldn't fit in memory (in my case, only possible with largest dff files), so the chances were greatly reduced.
With the current method in MC19, I could potentially run into this issue again (but like I said, I haven't so far).
I think MC (even being a 32-bit program) could allocate up to 4GB on a 64-bit system. This would reduce the risk descibed above for decompressed audio, but also increase loading times by ~4. Therefore, I'm not sure that would be a good idea as it would simply trade bad for bad IMO.
The only thing I can think of that would make everyone happy, is if memory playback becomes a dropdown selection: None, As file, As uncompressed wave.
-
The only thing I can think of that would make everyone happy, is if memory playback becomes a dropdown selection: None, As file, As uncompressed wave.
I would be OK with this.
I also think it should be possible to set a limit on the maximum buffer size Media Center is allowed to use (1GB is a lot on some systems) and would also like the option to cache the current and next file, so that you have the full duration of a track to cache the next one, instead of ~10s at the end of the current track.
-
been using MC19 for few weeks now, and find the new memory playback works great for me. very happy here.
-
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?
Also, is setting up a JRiver RamDisk possible? That should be of benefit. No?
-
Havent noticed any delays with it enabled even when playing DSD files from NAS.
-
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?
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.
-
Thanks for the explanation.
If I'm reading the correctly though, MC18 has better memory playback (which can't be the case).
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.
-
Thanks for the explanation.
If I'm reading the correctly though, MC18 has better memory playback (which can't be the case).
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.
-
Thanks for the explanation.
If I'm reading the correctly though, MC18 has better memory playback (which can't be the case)
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.
-
Thanks for clarification. So does that mean that MC19 has both (MC18 & MC19) memory play?
-
You can quickly search the build notes here:
http://wiki.jriver.com/index.php/Release_Notes
Search "memory" in the 18 and 19 releases.
-
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.
So far, the Subjectivist camp opinions are better or the same. I have not heard anyone who says "it sounds worse".
And if you want to know how, in theory, it can sound better, read:
http://www.audiostream.com/content/qa-john-swenson-part-1-what-digital
-
I have not heard anyone who says "it sounds worse".
Yes—to be clear—I don't think it sounds worse. I don't think it sounds better either.
And I think it should have to sound better to justify the increased CPU usage, increased memory usage, and reliance on disk/network I/O compared to MC18's implementation.
-
Here's a question:
When accessing a another library, does the client side still load a decoded file into memory if you also choose to have everything already decoded to wav from the library server? In other words is the library server taking a flac, decode it and then send to the client where the client then stores the wav to memory?
-
This thread should not be used for other topics. Thanks.
-
How does it process SACD ISO files and monolithic flac/cue files? Does it attempt to process the entire file or only the next track?
-
How does it process SACD ISO files and monolithic flac/cue files? Does it attempt to process the entire file or only the next track?
I think this is the biggest change, and they are handled as if they were individual tracks in the cache now.
-
Does it still apply to not use memory playback with a NAS in MC19 (Mac)?
-
Hi all,
thank you for your responses. Id did some further investigation:
I have done some measurements with the following albums, both 24 bit 192 kHz:
Wagner, Richard: de Vlieger: Tristan & Isolde by Hagen Philharmonic Orchestra (Album 1)
Berlioz: Symphonie Fantastique by Scottish Chambre Orchestra (Album 2)
t (sec)FLAC file size MB/sec Album/Track
3,11 353 MB 113 1 / 1
2,19 594 MB 190 1 / 3
3,37 261 MB 77 1 / 4
2,66 544 MB 204 2 / 1
2,51 569 MB 226 2 / 3
t is the time music starts playing after hitting the play button in mc19. Time is measured through my iPhone with an uncertainty of 10-20% (one must hit the MC19 button and the start button for the clock simultanously)
What I found strange is that the USB interface of the PC is USB 2.0 with max 60 MB/sec.; the WD MyPassport 2 TB has an USB 3.0 interface and cable.
I definitely expected lower MB/sec!!!!
Memory size increases e.g. for track 3 album 1 from 1.94 GB to 2,56-2,59 GB (after some time), so MC 19 has loaded the file in memory and starts decoding. CPU is between 10% - 44% peak, Core(TM)2 6600 with 6 GB RAM and an SSD for Windows 7 64 bit.
The WD MYPassport 2 TB disk is formatted with a higher NTFS block size as the default (4k) – media files are typical larger than 4k .-)
Bytes per sector: 512
Bytes per cluster 65536
File Record size: 1024 bytes
NTFS Version 3.01
As I understand reply #49 correctly : Playback starts before the full track is loaded into memory , but only if the file is > 1GB?
My core question is ( I am really uncertain about it), is it better to use an internal disk with SATA 6G interface of 3-4 TB size or an USB 3.0 external disk like my 2 TB one?
POWER LAN with ~ 200-300 Mbit/sec has a to low bandwidth to use a remote disk in my working room.
SSD would be best to reduce stating times but 2 TB = 2 x 1 TB is very expensive ~900 € in germany.
-
As I understand reply #49 correctly : Playback starts before the full track is loaded into memory , but only if the file is > 1GB?
Playback should start as soon as the prebuffering cache is full. By default that is 6 seconds of audio. It has nothing to do with the file size.
File size (e.g. a 50MB FLAC) has nothing to do with MC19's memory usage.
In MC18, the file was cached, so it would be the file size (50MB) plus the playback buffer. (about 30MB)
In MC19, decoded audio is cached, so a 50MB FLAC may use 100MB of RAM. (assume the FLAC is compressed 50%)
This is why, in MC19, there is very high CPU usage at the start of a track, as it decodes the full track into memory at the beginning of playback.
MC18 had lower CPU usage because it only decoded ~30MB of audio rather than ~1GB of audio.
MC19 will now cache up to 1GB of decoded audio, so any track which has less than 1GB of decoded audio (not file size) will be fully cached in memory. If the track requires more than 1GB (common with DSD files) then MC19 will only partially cache the track, even if its file size is less than 1GB.
Personally I think this is a big regression from MC18's performance, but audiophiles claim this approach can sound better. I disagree, and would rather see more efficient CPU and memory usage.
My core question is ( I am really uncertain about it), is it better to use an internal disk with SATA 6G interface of 3-4 TB size or an USB 3.0 external disk like my 2 TB one?
It should not matter. Reduce the prebuffer size if you want tracks to start faster.
-
How does memory playback interact with pre-buffer setting? The pre-buffer default of 6 seconds seems kind of redundant with memory playback enabled??
-
How does memory playback interact with pre-buffer setting? The pre-buffer default of 6 seconds seems kind of redundant with memory playback enabled??
...and, "Playback should start as soon as the prebuffering cache is full" .Full of what? I thought the 1GB cache had to be "full" of decoded audio before playback begins.
is the prebuffering cache loaded with decoded audio or disk data? is the pre-buffering cache "part of" the 1GB play from memory cache?
this is one question that with every follow up question and answer, I understand "play from memory" less... I assume it's just me and everyone else understands it.
-
...and, "Playback should start as soon as the prebuffering cache is full" .Full of what? I thought the 1GB cache had to be "full" of decoded audio before playback begins.
is the prebuffering cache loaded with decoded audio or disk data? is the pre-buffering cache "part of" the 1GB play from memory cache?
As I understood it, with memory playback enabled, the pre-buffering cache specifies how much decoded audio is required to be in the cache before playback will start.
It definitely doesn't wait for the 1GB cache to be full before playback begins.
-
Acoustically treat the listening room first, then worry about memory playback 2nd ;D
-
Acoustically treat the listening room first, then worry about memory playback 2nd ;D
Great advice! ;D. ....and no matter how mem play works, ? the old Grateful Dead files I'm playing this morning sound wonderful. :) :)
-
Great advice! ;D. ....and no matter how mem play works, ? the old Grateful Dead files I'm playing this morning sound wonderful. :) :)
the Maggie's are singing!
-
the Maggie's are singing!
I thought it was Donna ? 8)
-
Acoustically treat the listening room first, then worry about memory playback 2nd ;D
That doesn't always help:
(http://www.head-fi.org/content/type/61/id/938735/width/500/height/1000/flags/LL)
-
That doesn't always help:
Just need a different "treatment" for that environment. e.g. Wine or other adult (legal) beverage(s) ;D
-
Is the accessible memory greater with the 64 bit version? will this allow >1G size?
-
Yup.
The 32-bit build *should* allow up to around 3.5 GB, but not sure with MC 19. I seem to recall it being capped at around 1 GB.
-
Coming next build we'll have this:
Changed: The maximum memory playback size allocated is expanded to 4 GB from 1 GB on 64-bit builds.
-
Split Memory Playback Requests (https://yabb.jriver.com/interact/index.php/topic,116821.0.html)
-
Coming next build we'll have this:
Changed: The maximum memory playback size allocated is expanded to 4 GB from 1 GB on 64-bit builds.
Will this be available on JRMC23 or only 24 on?
-
MC24.
MC23 development is closed.
-
Coming next build we'll have this:
Changed: The maximum memory playback size allocated is expanded to 4 GB from 1 GB on 64-bit builds.
That build is available now:
https://yabb.jriver.com/interact/index.php/topic,116887.msg808379.html#msg808379