Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rayooo]

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)

[InflatableMouse]

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 .

[rayooo]

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.

[InflatableMouse]

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.

[kstuart]

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 ?

[rayooo]

Did you mean MC19 in that sentence ?

Ah, yes, meant MC19. my mistake, thanks!

[bulldogger]

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.

[kstuart]

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.

[rayooo]

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!

[6233638]

* - 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.

[InflatableMouse]

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.

[6233638]

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.

[Blaine78]

been using MC19 for few weeks now, and find the new memory playback works great for me. very happy here.

[jtwrace]

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?

[dean70]

Havent noticed any delays with it enabled even when playing DSD files from NAS.

[6233638]

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.

[jtwrace]

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.

[rayooo]

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.

[6233638]

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.

[jtwrace]

Thanks for clarification.  So does that mean that MC19 has both (MC18 & MC19) memory play?

[MrC]

You can quickly search the build notes here:

    http://wiki.jriver.com/index.php/Release_Notes

Search "memory" in the 18 and 19 releases.

[kstuart]

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

[6233638]

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.

[gabeg]

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?

[JimH]

This thread should not be used for other topics.  Thanks.

[dean70]

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?

[6233638]

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.

[jtwrace]

Does it still apply to not use memory playback with a NAS in MC19 (Mac)?  

[Manfred]

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.

[6233638]

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.

[dean70]

How does memory playback interact with pre-buffer setting? The pre-buffer default of 6 seconds seems kind of redundant with memory playback enabled??

[rayooo]

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.

[6233638]

...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.

[HiFiTubes]

Acoustically treat the listening room first, then worry about memory playback 2nd 

[rayooo]

Acoustically treat the listening room first, then worry about memory playback 2nd 

Great advice!  . ....and no matter how mem play works,  ? the old Grateful Dead files I'm playing this morning sound wonderful.    

[HiFiTubes]

Great advice!  . ....and no matter how mem play works,  ? the old Grateful Dead files I'm playing this morning sound wonderful.    

the Maggie's are singing!

[kstuart]

the Maggie's are singing!

I thought it was Donna ? 

[kstuart]

Acoustically treat the listening room first, then worry about memory playback 2nd 

That doesn't always help:

[rayooo]

That doesn't always help:

Just need a different "treatment" for that environment.  e.g. Wine or other adult (legal) beverage(s)  

[stanzani]

Is the accessible memory greater with the 64 bit version? will this allow >1G size?

[Awesome Donkey]

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.

[Matt]

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.

[JimH]

Split Memory Playback Requests

[Bigguy49]

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?

[JimH]

MC24. 

MC23 development is closed.

[JimH]

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