Print

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

[sandalaudio]

Hi.

I have been having issues with long DSD files (e.g. 4GB+) being truncated on playback, and it turned out to be related to the Memory Playback option in JRiver (e.g. "Load Full File (not decoded) into memory").

As shown on the screenshot attached, a 60 min DSD128 file shows up correctly on Library view, but shows 9:16 upon playback and abruptly cuts out at that point.

Disabling the Memory Playback option will allow these large files to play correctly for the full duration.

Interestingly, the PCM files of similar 4GB+ file size does not experience this issue, so only seems to happen to DSD. I am running the latest MC 24 on Windows 10 64 bit with latest updates, and have 16GB of onboard RAM.

FYI I had previously reported a similar issue where many of my large DSD file gets physically damaged when I edit the tag (file truncates and becomes a very small file). I still haven't found resolution to that problem but maybe these are related? https://yabb.jriver.com/interact/index.php/topic,116645.0.html

[Matt]

Are you on the 64-bit build of MC?  If not, could you try it?  Thanks.

[sandalaudio]

Yes Sorry I should have mentioned that I am already on the 64bit version of JRiver 24.

Just as a follow up, even if the Memory Playback is enabled, once the file size becomes very big, JRiver seems to abandon Memory Playback and directly plays off disk (I know this because the initial file caching does not occur, and playback starts immediately), in which case the the truncation does not occur.

Attached is a summary of what I found with various dummy (white noise) files I created. Maybe the physical threshold is subject to the amount of physical RAM allocated?

[Awesome Donkey]

I thought the maximum playback size that's supported in the 64-bit builds is 4GB? I'm assuming if a file goes over that limit, memory playback simply won't work and is abandoned? In the case of DSD files, I'm assuming weird things can happen. Anyways, maybe an option for auto exempting DSD files (over 4GB in size) or files over 4GB in general from memory playback would help prevent this from happening?

Actually, here's a little request that might help determining if memory playback is working: If a file has been added to memory and is playing it back, show memory playback status in the Audio Path?

[sandalaudio]

Thanks. If that 4GB limit is true, then there must be some strange "range" of filesizes for DSD where JRiver attempts to do memory playback and fails.

I can easily avoid this issue by simply disabling memory playback as needed (I only have a few songs that are bigger than 4GB anyway).

However, I only discovered this when I was trying to figure out why tag editing on certain large DSD files corrupt them (as mentioned in my first post), so I thought maybe these two issues could be inter-related. I am just imagining that JRiver temporarily puts the file into memory for tag embedding, and that embeds the tag at an incorrect location, thus corrupts the file. This is just my wild guess.

It just seems coincidental that those large DSD files that causes memory playback truncation also causes file truncation by tagging.

I take it back. After investigating more, I found that the tagging issue is not related to Memory Playback. I have some 4GB+ DSD files that tags correctly (even if memory playback causes truncation), whereas others that do cause file corruption issues. I need to investigate this a bit further.

[Awesome Donkey]

IMO, if a file is over 4GB MC should know right off the bat (detecting file size before initializing memory playback) and never attempt memory playback for that file. I think the limit for the 32-bit builds is 1GB, so the same could apply there too.

[dtc]

Unfortunately, there is no automated way to turn memory playback off and on on the fly, and memory playback is not zone specific. So, there is no easy way that I know of to turn it on and off depending on the size of the file.  It really seems like MC should handle a large DSD file gracefully, without user intervention.

[sandalaudio]

Thanks for the comments

It is unlikely to come across a 4GB+ DSD file for most people, but I have recently encountered several situations, for example classical symphonies with very long movements, or for digitising LP record and open-reel tapes, in which case, storage is cheap and many people choose to use DSD256 just for the peace of mind.

It's probably some glitch in how JRiver flags DSD for Memory Playback, so I hope the problem gets rectified eventually.