Print

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

[tbng]

I have many .dsf files, a few with a sampling rate as high as 11289600 Hz.  With each of these recordings the music will occasionally "stick," i.e., for five seconds it will re-play the same short section and then move on.  Rather surprisingly, today for the first time it did it with a 2822400 Hz recording.  This issue occurred in v.23 as well.  i am using six-second pre-buffering and load full file (not decoded) into memory.  I'm using Windows 7, 64 bit with an I7-4790S @3.20 GHz processor with 32 Mb of RAM.  Any solutions?

[Matt]

If you turn off memory playback, does it make any difference?

[swiv3d]

 I7-4790S @3.20 GHz processor with 32 Mb of RAM.
I hope that's 32GB of RAM or you will have trouble playing anything! If your files are greater then 4GB then playing from memory will definitely cause problems.

[tbng]

Ah. . . yeah, that's 32Gb.

[swiv3d]

Have you tried turning off memory playback?

[tbng]

Here is the latest.  In trying to play a file that is 4.93 Gb in size with loading the decoded file into memory, JRiver stopped sticking and started crashing, three times in a row at the same place in the music.  I tried playing it a fourth time but fast forwarded several minutes.  I got past the problem point, but JRiver merely crashed further along in the music.  Then, I turned off memory playback, re-played it, and the piece played all the way through without incident.

I am wondering.  Is it a coincidence that JRiver's buffer size is 4 Gb and the file size is 4.93 Gb?  Is the rolling buffering functioning properly?

[swiv3d]

I am wondering.  Is it a coincidence that JRiver's buffer size is 4 Gb and the file size is 4.93 Gb?  Is the rolling buffering functioning properly?

Obviously not, but as I said trying to load a file greater than 4gb into a 4gb space is asking for trouble.

[tbng]

But those file sizes do exist, and more are hitting the market every day.  Isn't JRiver's buffering algorithm supposed to handle that?  In v.23, how did it handle loading a 1.5Gb file into 1 Gb of memory?

[swiv3d]

Can't speak for JRiver, but if non memory playback works what's the problem really?

[dtc]

Can't speak for JRiver, but if non memory playback works what's the problem really?

The problem is that memory playback should work for all tracks. You should  not have to turn it off to play large tracks and then turn it back on for other tracks. What do you do if a large track is in a playlist? And, since playback from memory is not zone specific, you cannot use zone switch to deal with this situation.  Think of a comparable situation with a DSP setting. Can you imagine having to turn the option on and off to play specific tracks?

If a track is too large for memory, MC show handle the situation smoothly. The user should not have to intervene to play that specific track.

[Matt]

If the file is larger than 1.5 GB then the memory reader won't engage.  And it should be totally safe to engage on files that size and smaller.

But it's possible the hit of loading the 1+ GB file into memory makes playback hiccup.

It's possible increasing the pre-buffering time in Options could help that, but I'm not sure.

[swiv3d]

My point was that as buffering isn't working effectively at the moment, switching to non memory playback will allow the files to play whatever playlist they are in. Perhaps the devs will be able to sort out buffering but until then just select non memory playback and everything works.