Yeah, like I said it's probably hitting the limit and causing this issue. The only ways around it is to split the file into individual tracks or disable memory playback.
It's worth noting that it doesn't make sense for JRiver to further increase the memory playback limit. At bare minimum most 64-bit PCs these days have at least 8GB RAM - honestly if you're running a 64-bit Windows OS on an older machine with only 4GB RAM, you should use the 32-bit version of MC instead of the 64-bit version of MC. If the memory playback limit was increased to 8GB and a client only has 8GB of RAM, you risk crippling your performance on the client by using all of the system's resources (which the system needs some of it to perform correctly) if you attempt to load a very large file into memory.
There is one idea that comes to mind that might also workaround this issue (I can't recall if MC already does this): if memory playback is enabled, and a user is trying to load a file that's larger than the 4GB (or 1GB) limit, MC shouldn't attempt loading the file into memory and just playback the file as-if memory playback was disabled. Another idea would be changing the not-zone specific memory playback to where it can be disabled in zones. But I suspect it's an "all or nothing" type of deal.
