JRiver tips and techniques: user experiences repository

[Skeptic]

Thought I'd add some more detail to fixing ALL CAPS

There is a Clean File Properties tool which makes this a lot easier. It's in the library section of the tools menu.

[Skeptic]

iTunes11 seems to have gone in the same direction so I've dumped that and gone back to version 10 which allows easy layout of album covers. I have playlists of artists or genre and within that its all album covers. Is there a way to do that in JRiver? If so, will it take hours of scripts and messing about?? iTunes10 makes it all easy and I'm all for easy.

You can set up JRiver almost any way that you want, and it's not very difficult.

 

To create a view that is like the one in the image you posted, right-click the audio heading on the left side of the applications, add a library view, and start with a new empty view. (last item)

Select View As: Panes

Show Categories in this Order - Album Artist (auto)

View Details - Panes: Left

 

Now click ok to see the view you have created.

Click the tab at the top which has a downward facing arrow, and select list style: album thumbnails.

 

Now you have an A-Z list of all the artists in your library down the left side of your screen, and all the album art on the right.

You can adjust the size of the images with the slider in the upper right.

 

 

If that is not what you are looking for, try creating another empty view, but this time change the view type to categories instead of panes.

Now add the categories you want to the list. You might want to try: Album artist (auto), Year-Album.

Click ok to see the view you have created.

 

Now you will have a big view of all the artists in your library displaying album art.

Double-click on an artist and it will show you the art for all of their albums.

Double-click on an album and it will show you the tracks.

 

I think there is also a tool to get artist images from Last FM if you want images of the artist instead of their albums in the top-level view. I don't know how well that works as I didn't want that.

[Skeptic]

What tasks should I perform when importing music?

 

ie What does each of the selections of analyze audio for audio files, fix broken links, write file tags......mean? Should I be selecting them?

 

Thanks

Analyzing audio for your files will fill out information about the files which is used for Volume Leveling and other features. It also gives you useful information about your files such as Dynamic Range (DR) which is equivalent to the TT-DR meter/Dynamic Range Database

 

Building thumbnails will mean that thumbnails are built in the import process rather than the first time you view the files in your library.

 

Get cover art will get cover art from the internet if none currently exists for the files.

 

Ignore files previously removed from library will not import files which you have deleted from the library, but still exist on the disk in a location that is scanned by auto-import.

 

Update for external changes means that editing file tags in another program will update those tags in the JRiver library.

 

Fix broken links should update the library to point to the new location of files if you have moved them outside of the program. (you should use their tool for this though)

 

The write file tags option means that anything changed in the import process will be written to the file instead of only being written to the JRiver database.

[Skeptic]

Thanks, so it sounds like I should check each one.

I don't use the cover art, fix broken links, or write file tags options.

 

I don't want JRiver making those changes, and writing file tags may slow down the import process.

[Skeptic]

Anyway, I'd like to create a view which just shows flac files but which still retains the Artist/Album file structure. Can this be done? Not by me anyway. Can someone help me achieve this please? I've followed what I thought was the way to go but it never works right. What am I missing?

Do you actually want to view the file structure, or just the information contained in the tags?

If you only care about the tags, this is very easy to do.

 

1. Right-click the "Audio" heading in the tree and create a new library view. Use an Empty View and call it whatever you like.

2. Set the view type at the top to be a "Categories" type.

3. Add "Album Artist (auto)" and then "Year - Album" for your categories.

4. In the "set rules for file display" add a rule which is "File Type is not MP3" or you could use "Filename (path) does not contain \mp3\" if you prefer.

[Skeptic]

Handling tracks with multiple artists, or compilation discs where each track is by a different artist can be a bit tricky, depending on how your files are tagged.

 

If the Artist field is tagged as "Eminem feat. Dido" then that will show up as a unique name for a single artist.

What you really want is to have each artist separated by a semicolon such as "Eminem; Dido" which will list that track under both "Eminem" and "Dido" in a view which lists tracks by "Artist".

 

 

The "Album Artist" field is used to specifically list an album under the name of a single artist.

So an album may have collaborators (e.g. Dido) but the album itself is an Eminem album - so you would use "Eminem" in the Album Artist field.

 

 

"Album Artist (auto)" is a special field in JRiver which tries to group your albums under a single heading automatically if the "Album Artist" field is empty, without requiring you to manually fill it out for all your albums.

 

 

If an album has Eminem listed as an Artist on every track, even if some tracks also have collaborators listed, grouping by "Album Artist (auto)" should only list the album under "Eminem" - it would not be listed under "Dido" (or any of the other collaborators) as she only contributed to a single track.

 

If you have a compilation album (e.g. "Top 40 hits" ) where every track has a different artist, the album will be listed under "(Multiple Artists)" rather than being listed under 40 different artist names.

 

 

If JRiver calculated the wrong value for this grouping (sometimes an album will be listed under "Multiple Artists" when that's not what you want) or if you want to override it with a specific name, you can manually fill out the "Album Artist" field, which takes priority over the automatically calculated one in that view.

 

For example, if you wanted that "Top 40 Hits" compilation to be listed under the name of whoever created it, rather than "Multiple Artists" you would fill out the Album Artist field with that name.

 

 

I hope that makes things a bit clearer.

[Skeptic]

Edit- I've followed your instructions above and all is well. What's the audiophile view on "Volume Levelling"? It seems like a good idea to me since my seating position isn't near my O2 amp and getting up and down to change levels is a bit of a pain. If it degrades sound quality though then I can live without it.

Volume Leveling works well in my experience.

 

Technically you are going to be slightly raising the noise floor on the tracks which have their volume reduced rather than inceased, but 24-bit audio's noise floor is so low that it's an inaudible change on my system.

What do people think about JRSS? I'm not sure I even hear a difference. I notice it's on by default but turning it off seems to make little difference. Is it wise to use it or does it somehow interfere with bit perfect playback?

JRSS is only used when up or downmixing audio. If you're only playing stereo music to a stereo dac, it won't make a difference.

[Skeptic]

It is great, but for the life of me, I still don’t understand why an album isn’t just an album no matter what artist fields are involved. If you call up an album, you should get the album no matter what other kind of meta data is associated with the files. This is the kind of stuff that prevents this technology from having a wider consumer appeal.

Well here is the most obvious reason as to why that is: what do you do when you have two albums with the same name, by different artists?

 

If you simply group by the album name, you now have two albums by completely different artists being grouped together as a single album.

 

But this is why the Album Artist field exists - to place an album under a single heading.

 

And in JRiver, you have the Album Artist (auto) field, which calculates an Album Artist value automatically.

Please read this post for more information on it.

 

I am playing DSD files and the e28 reports DSD at 2.822Mhz. JRemote and JRiver are both reporting 352.8kHz (or 384….I cannot remember which it is). What do I make of this?

You need to enable bitstreaming if you want native DSD playback.

If it's reporting 352.8kHz you are converting to PCM.

 

You may have enabled DSD encoding in the DSP Studio, instead of DSD Bitstreaming in the audio options.

Has anyone played around with the settings for buffering? If so, what have you settled on? The JRiver recommendation for prebuffering is 6 seconds, the main buffering setting is 100 milliseconds.

I wouldn't touch it if you aren't having any problems. Those settings are for fixing playback issues.

[Skeptic]

Skeptic, it is not true that he is not doing bitstreaming. He is; he already said the exasound shows DSD. He is NOT converting to PCM, nor am I.

If JRiver says that it's playing 352.8kHz 64bit audio and the DAC is receiving DSD, you are using DSD Encoding, which means it's being converted to PCM and then encoded back to DSD.

 

If you are bitstreaming DSD, the audio path should say that it's outputting 2.8MHz 1bit audio.

 

I have the same thing often with jremote...showing 352.8k (happened last night) on the jremote now playing screen, but the DAC is fine and playing DSD normally. JRiver is reporting accurately for me too. What is doubly strange is that 352.8k is DoP's carrier for DSD128 not 64. Anyway, it's a Jremote reporting anomaly that does not affect sonics.

Check what JRiver itself is saying. This might be a bug in JRemote.

[Skeptic]

?? Skeptic, sorry but you need to read these posts. Do my statements "JRiver is reporting accurately" and "It's a jremote reporting anomaly" mean anything? Yes, skeptic, it's a jremote issue not a JRiver or user or DAC one.

If you check Gumby's post, he says that both JRiver and JRemote report 352.8kHz on playback, and the DAC is reporting DSD.

 

This will only happen when you are using DSD Encoding, and not DSD Bitstreaming.

When bitstreaming, JRiver will report 2.8Mhz 1bit not 352.8kHz 64bit.

[Skeptic]

I'm able to set up shuffle mode by going to files or albums but I cannot set it up using the JRemote I have to set it up through JRiver. Is there something that I'm missing?

I think you need to have the "All" item displayed in your views if you want to do this.

 

In the Media Network settings of JRiver, open up the advanced section and customize views for Gizmo.

 

Select your view, and there should be an option to display 'All' as a choice.

Close JRiver and the Media Server tray application, if it is running, and restart it.

Now in JRemote you can hold down on the "All" item and select "Shuffle and play".

 

I think I have duplicated what your screen shot shows. I can't get it to show this audio view on my Ipad using JRemote. I was able to create a view for my DSD files using rules along with another view. Both show on JRemote after I closed out rand Jremote. I can't get the View/Pane/File Sample I created to show on my remote.

JRemote (Gizmo) views are completely independent of normal library views, as are theater views. As above, they are customized in the Media Network options.

 

You can import regular library views into Gizmo.

[Skeptic]

I keep the system on 24/7 now, and I don't let the drives spin down either.

Since doing that, I have had far fewer hardware troubles/drive failures.

 

I just shut it down once every two weeks or so to clean all the fan filters.

If the filters were external, I wouldn't shut it down at all.

 

I know that may not be the most "green" thing to do, but it's cheaper than replacing drives, and it doesn't use that much power when it's sitting idle.

[Skeptic]

i would probably do files view and make sure catalog # is one of the panes, and sort on it, so you find only those albums that have catalog #'s; otherwise all your albums will have parentheses after them (empty ones if no catalog #)

Use Delimit instead of just adding the Catalog # to the end.

 

=[Album]Delimit([Catalog #], /), / /()

 

That way it will only add the parentheses if [Catalog #] has a value.

Expression Language - JRiverWiki

[Skeptic]

The internal format for DSD to PCM conversion is at 1/8th the DSD rate. For 1xDSD that is 352.8kHz

 

The preference used to be for "Above 192kHz" which meant that 1xDSD (352.8kHz) would use that setting.

 

More options were added recently, so 1xDSD is now handled by the 352.8kHz setting rather than "Above 384kHz"

[Skeptic]

They recently changed some things to do with how DSD is output, to try and keep it a continuous stream without breaking the connection to the DAC, as many devices would have a click when the sample rate of the file changed, even though it was all being converted to DSD.

 

It seems to have introduced a number of issues that are being worked on. Try going back to an older version.

 

Help > Update Channels > Disable Automatic Update

Help > Update Channels > Open Download Folder

 

There should be 5 or more previous versions to choose from. Pick the earliest one and see if that works until they fix things.

[Skeptic]

Thanks. I uninstalled 19, including removing registry settings. Went back to 18.0.202. That works.

 

Hopefully MC20 will be better in this area.

You should only have had to go back a few versions in MC19. It's been working fine all year until this change in the last couple of weeks.

 

I have noticed a trend recently though where they implement a "quick change" to a feature like this which does what they intended, but then breaks a number of other related things.

 

 

Another example would be when they expanded the Output Format options from 44.1-192kHz to 44.1-384kHz.

This was a poorly considered change which broke playback for a number of people until they reconfigured those settings.

[Skeptic]

Hi Folks, please welcome me to the MC brother/sister hood :-) I just retired my Squeezebox and have pressed a i7 ASUS laptop into service with MC 19. Mainly because I have a ifi iUSB and a bel Canto uLink and so can experiment. But pl. humor me.. Initially I thought the SQ was not as good as the Squeezebox and after playing with different output devices and fidelizer, this morning fidelizer+WASASP (with no event) sounded good I think. Let me know what other low hanging fruits are there before I get to power supply, CAPS and other crazy stuff. (BTW, I still cannot seem to control the output rate of DSDs .. it seems to pick 192Khz because that is what I set as the max for anything more than 192Khz)

You should use event style if your hardware supports it, as it allows a device to pull audio from the PC as required, rather than having the PC push audio to the device.

 

DSD to PCM conversion uses the 352.8 kHz setting.

[Skeptic]

Implementing memory play is a good example of that. Their first attempt was not very good, and I think they were more than a little surprised that Audiophiles could tell it wasn't up to snuff and complained about it. Their second attempt at memory play worked much better and garnered a lot of praise for the audiophile community. I think that surprised them almost as much, since they honestly did not believe it would make any audible difference. Now it works flawlessly, so far as I can tell.

You have that backwards. Their first implementation was very good. It used only as much memory as necessary, and was totally immune to slow disk/network access during playback.

 

Now it's a CPU and memory hog that is susceptible to interruption during playback, especially with SACD.

I can't use it at all on my system unless JRiver is the only application running.

 

It's still far from perfect, and is in a worse state than it used to be before the "audiophile" changes were made. But JRiver don't seem to care about performance issues now, only adding new features.

 

It is intriguing how little they believe hardware makes a difference, but I was glad to see this function included. When memory playback is selected in JRMC, do you know how much it loads: album, song, # of songs?

In Amarra there is an option to choose, but I could not find it in JRMC.

It tries to decompress the current song into memory in as quick a time as possible, up to 1GB.

If the uncompressed audio is larger than 1GB (DSD/SACD) it will buffer several times during playback.

Each time it buffers is a chance for interruption since it's accessing the disk/network again, and CPU usage jumps to 100%.

The next track begins to buffer in the last 20 seconds of the current track - which is why playback stutters at the end of a track on slower systems now.

[Skeptic]

FWIW, Matt has stated explicitly on Interact to disable memory playback when using NAS.

It's a fixable problem. Just one they don't want to address.

[Skeptic]

Maybe there is a hardware element to this. My CAPS is a Micro Zuma with an I7 and 16GB of RAM. I can monitor my Ethernet connection and watch a burst of network traffic at the beginning of each song, otherwise the network is dead (using a NAS). The playback is very good and the CPU usage is rarely above 1%. Memory playback seems to work well for me.

That's exactly why it is not recommended, as it only leaves 20 seconds at the end of each track to load the next one into memory or else playback may be interrupted.

They could be a lot smarter about it, like always caching the next two tracks in memory instead of only the currently playing one, and it would use less memory than the current playback system if they stored compressed audio instead of decompressing the file like they do now.

[Skeptic]

Whoa there- many many people, including me use memory play with files on a NAS and JRMC. Skeptic is incorrectly presenting this as an absolute problem. I am not even sure Skeptic's description is even accurate.

JRiver are the ones saying not to use it with a NAS, not me.

I explained the reason why they say this. It can work in some setups if your network connection is active and fast enough.

 

If you listen to a long track (say 20 minutes of classical music) and your network adapter (e.g. wireless card in a notebook) and NAS disks go to sleep, it might take longer than the 20 seconds or so JRiver give it to transfer and decode the next track. Depending on the hardware it might be significant and could even halt playback.

 

JRMC gives problems when ran on a skimpy processor, like old single threaded Atoms. Almost sny modern machine does not see these problems. Inuse an i5 based mavhine and have zero troubles.

Not true with SACD if you aren't bitstreaming. Try a multichannel SACD or DFF track. (not DSF)

 

And like I said, the folks at J. River are accomodating to audiophiles like us, even though they do not always believe the changes and features we ask for make a difference.

 

Lastly, this insistance some of you guys have on limiting processes and such is a big issue to swallow. Processes do not usually take up any CPU cycles unless they have some work to do. I would rather see concentration kn getting software to native 64 status, which woukd eliminate any memory constraints that may still exist in 32 bit software.

I'd rather see them use memory more efficiently so that would not be necessary. Store the track in RAM - or several - which is going to use less than a 1GB, instead of decoded audio which can be significantly larger.

 

A 580MB, 21 minute 6ch DFF becomes 7.4GB when you store it uncompressed.

This means the 1GB buffer has to be emptied and refilled eight times during playback, which requires significant CPU and disk/network access each time, instead of playing from a small buffer that results in a small but constant amount of CPU usage and no disk/network access.

Each time it does this, it interferes with anything else running on the computer, which did not happen before.

 

If you were to store the compressed tracks in memory, 1.6GB would store the entire album, resulting in zero disk/network access during playback. You would need 22GB with a 64-bit version of JRiver to store the album in memory uncompressed, and there would be 100% CPU usage and disk/network access for several minutes while it does this.

 

It's a stupid design to placate people who either think they can hear the difference when their CPU is busy/idle or believe that lossless/uncompressed tracks sound different.

And even if you do believe that is true, the current system results in higher CPU and disk/network access than before.

 

It's worse in every single way, no matter what you believe about things like CPU usage during playback.

[Skeptic]

It is not hard to build home networks plenty fast enough to avoid this these days. This should not be an issue for anyone, and certainly not for anyone spending multi-thousands of dollars on audio equipment.

It is not speed, but latency that is the issue. If JRiver cached the next couple of tracks instead of only allowing 20s to transfer and decode the next track, it would not be an issue on anyone's setup.

Even with a fast network, hard drives in a NAS can be slow to spin up.

 

I don't think it's fair to assume that everyone running JRiver is spending thousands and thousands of dollars on gear either.

 

I only have a couple of DFFs, but they have no trouble at all streaming. No hiccups, stutters, or whatnot.

If JRiver is the only thing using your computer, it's probably fine.

If other applications are running and accessing the same disk/network (e.g. copying files) and the current track requires more than 1GB RAM, playback can be interrupted in the current system, or it can pause for several minutes between tracks.

 

Well, believe it or not, we are saying something like the same thing here. You have to have a 64bit memory model to take advantage of more than about 3.6GB of RAM. With uncompressed audio files growing very large - well - one does need much more memory.

Do you really think it's smart moving to 64-bit so that caching a full album would require 22GB of RAM when 1.6GB will do the same job?

 

With the current 32-bit app and its 1GB buffer, you could already keep three full tracks in memory at once, or more depending on the format, instead of having to refill the buffer 8x during playback of a single track.

 

On the other hand, I am not convinced that totally decoding the file in a memory buffer is advisable.

It's not. Converting that same 580MB track to uncompressed WAV took two and a half minutes of 100% CPU usage on a fast quad-core i5, and required 3.9MB/s I/O.

 

If you believe that CPU usage and disk/network access affect playback quality, do you want the first two and a half minutes of a 21 minute track affected by this?

If you had a 64-bit version and decoded the full album into RAM, the entire first track would be played back with 100% CPU usage.

 

If it takes 150s of 100% CPU usage to decode the track as quickly as possible, that could be 21 minutes of 12% CPU usage instead, and only 0.46MB/s I/O.

With only 12% CPU usage, three of the CPU cores could sleep with only one being required for playback.

 

You also have to consider that many people use their computer for other tasks with music playing in the background, or want to play music to multiple rooms at once. If playing a single track eats up 100% of the CPU, there's nothing left for anything else.

 

That is why SACD tracks like this one which have to fill the buffer 8x over the course of 21 minutes is a serious problem, since it means that everything else on the PC is interrupted every few minutes, or other tasks on the PC can potentially interrupt playback in JRiver.

 

As I said, I think it is better than what they started with, and I believe I can hear a difference. That despite suspicions of exactly how they did it. (i.e. bumped up the buffer size, added a thread, etc. )

If you believe that you can hear a difference, do you hear an improvement?

Disk/network activity and CPU usage can be much higher during playback now.

 

With PCM formats this is a much smaller problem, since they are generally stereo, fit inside the 1GB buffer, and are a lot easier to decode compared to DST compression.

 

It would still be much more memory efficient to store compressed tracks rather than decompressing into memory, and this efficiency would allow you to store multiple tracks in advance, to greatly reduce disk/network access during playback, and the possibility of interruption.

[Skeptic]

If they are worrying about the implementation of memory play, I suspect it is pretty safe to say they are an audiophile and have spent quite a chunk of change on their audio gear.

First and foremost, the feature should prevent interruptions during playback.

Whether or not it improves audio quality should be a secondary concern.

 

Since all lossless and uncompressed formats should sound the same, it should have no effect on quality.

 

If it is a music server, JRMC should well be about the only thing running on it. You can run other apps of course, but it is a compromise. The same is true of pretty much any other high end player as well, A+, HQPlayer, XXHigh End, etc.

Few people own a computer solely dedicated to a single task. The strength of computers is that they can do many things.

I doubt JRiver would say that the program is intended to be the only program running on the computer.

 

If it did the same job, no. But it doesn't, and yes, it is smart to move up to 64bit processing now and be prepared to handle computers that routinely come with terabytes of memory. It isn't that far in the future.

The computer is always playing uncompressed audio from memory unless you are bitstreaming. The only difference is whether you decompress the whole thing at once with a lot of CPU usage, or do it in small chunks that consume an insignificant amount of CPU time during playback. So it is doing the same job.

 

Considering that the memory playback feature had audible glitches for several months with tracks that exceeded the 1GB buffer, and no-one on here seemed to notice, I don't think anyone would hear a difference between storing the tracks in their native format or uncompressed.

 

It's amazing the things which people claim to hear on these forums, yet they somehow miss real problems like that.

 

I cannot understand why JRiver "caved in" and made this change, since their stance has generally been "bits are bits" and they still don't consider the memory playback option to be a quality feature. If it's not a quality feature, and it makes playback more susceptible to interruption (the opposite of every other program with this feature) when what exactly is it supposed to do, except inflate the amount of RAM the program consumes?

 

 

Personal computers have been limited to 32GB for years now, with many designs being limited to 16GB.

You're crazy to think that music playback needs anything like that amount of memory, or if you seriously believe that personal computers will be using 32x as much RAM in the near future.

It's true that DDR4 is going to be increasing this limit with 16GB DIMMs, but that is not going to be cheap, and there are still no consumer platforms using it yet.

 

JRiver uses a tiny amount of memory for music playback with the memory playback feature disabled.

 

Moving to 64-bit breaks a lot of features and compatibility. It will probably happen eventually but there is no need for it.

 

Only if you assume I am converting the album from DSD to PCM, which is something I just wouldn't do. I almost certainly would do the opposite though, and in fact, I do convert PCM to DSD for playback. If I really wanted to play it as PCM, I would convert it offline though.

When you have a lot of hardware devices which all support different formats, some supporting native DSD and others not, it would double or triple the amount of disk space required if I did offline conversions for each device.

I use JRiver because it is supposed to be able to handle this.

 

Even if you are bitstreaming DSD, DST compression can use quite a bit of CPU power.

 

I honestly do not know where you are getting these numbers from- I can decode and re-encode a file much much faster than that, so I think your numbers are a bit off.

A 20+ minute, six-channel, DST-compressed SACD track? (all multichannel DSD should be DST compressed in its original SACD/DFF format)

 

Well, yes and no. That PCM has to be decoded before it is buffered and sent to the DAC.

Decoding PCM is trivial. Stereo 24/192 tracks use <0.1% CPU to decode on my computer.

There is essentially no difference in CPU usage between using memory playback or not with PCM. If anything it seemed to be slightly higher.

 

The only thing memory playback does for PCM is increase the amount of memory the program uses, and cause there to be higher CPU usage in the middle of a track if it doesn't fit into RAM when uncompressed.

 

If they stored the native format rather than uncompresed audio, and stored multiple tracks in RAM (you could fit half an album of high res FLAC into 1GB) then memory playback would be a useful feature for eliminating disk/network access during playback instead of a placebo or a detriment.

 

The network queuing algorithm in JRMC is suboptimal, I will grant you that. It causes and is susceptible to packet queuing delays, which cause what you describe as latency. However, NAS that are not predictive and power down when they should not, networks too congested to reliably transfer traffic in a timely manner, and/or computers that are memory limited and depend upon weak processors are not something the J. River can be blamed for.

No, but it is something they can design against.

Which would you rather see, A or B?

 

1A) 1 track of 24/192 decoded into memory, taking up 700MB of RAM, using 0.1% CPU activity, with 20 seconds to buffer the next track.

1B) 4 tracks of 24/192 stored in its native format in memory, taking up 700MB of RAM, using 0.1% CPU activity, with no disk activity relating to the current track, and 10+ minutes to buffer the next track.

 

 

2A) 1 track of DSD partially decoded into memory, taking up 1GB of RAM, using 100% CPU activity every few minutes, buffering several times during a single track, with 20 seconds to buffer the next track.

2B) 2+ tracks of DSD stored in their native format, using up to 1GB of RAM, with a constant low-level of CPU activity, no disk activity relating to the currently playing track, with 5-10 minutes to buffer the next track.

[Skeptic]

@Skeptic - looks like you want people/JRiver to accept your design idea of keeping data compressed in memory.

It's how things used to be. And performance used to be good before.

A return to storing compressed data would bring better performance, use less ram, and allow for more tracks to fit into the same amount of memory to ensure that playback is completely immune to interruption. It's better in every way.

 

As somebody who has programmed with uncompressed/compressed data on disk/memory my take is - the performance benefits can only conclusively be told with a benchmark.

This is easy to test if you have a license for v18 (compressed audio) and 19 or 20 to compare. (uncompressed)

 

If you have memory playback turned on you are an audiophile and now we are in a different discussion.

It should first and foremost be a performance feature where you trade memory for better performance. (i.e. immunity to slow I/O)

That is the whole point of memory playback. It's not supposed to be a quality option, though "audiophiles" seem to think that it should be.

 

I am with Paul on this. It is highly likely with the current CPU powers, a single thread de-compressing and playing back the data may lose the 'supposed' advantages of memory playback.

Memory Playback in JRiver has CPU usage whether it is on or off.

If it is on, you have 100% CPU usage every few minutes during playback.

If it is off, you have around 1/10th the CPU usage constantly.

 

100% CPU usage every few minutes is disruptive, to the point that it can actually interrupt its own playback on slower systems with small hardware buffers.

 

That was a long time ago, no memory player glitches in v18, v19, or v20, if memory serves me correctly. It just plays and plays.

It was broken in v19 until 19.0.90 several months after release. And apparently no-one here noticed.

This was an actual problem, compared to the imaginary problems that people seem to think memory playback is supposed to solve.

 

Sez who? Mine certainly isn't

Intel's consumer CPUs are limited to 32GB.

 

Do remember that even running JRMC on a 64 bit OS is a plus- as the OS will use all available memory to buffer disk access, providing exactly what you are asking for. In other words, turn memory play *off* in JRiver and you get exactly what you are asking for.

...

Exactly what you get with memory play turned *off*. Best of both worlds for you?

You seem to be misunderstanding the problem, and/or how playback in JRiver works.

 

Again, 64-bit breaks a whole lot. It breaks VST plugin support and video playback completely. Input plugins for at least some of the audio formats are probably affected too.

 

As an example, dBpoweramp are still ironing out bugs from their switch to 64-bit. I've only used it to convert between FLAC and ALAC and already had to report several issues. Switching to 64-bit is not a trivial thing for something as complex as JRiver, and it should not be necessary at all if they use their available memory more efficiently.

 

Switching to 64-bit so that the program can use almost 14x as much RAM to perform the same task is ridiculous.

[Skeptic]

Are you checking this on Windows or MAC ? What tool ? If it is another core/thread that is 100% loaded then it is ok. From a sound quality point of view the writing thread should respond to IO from the device right away, way within the max limits allowed. May be that 1/10 CPU is not good enough that way.

At work, depending on the query/processing (IO vs CPU) we use compressed or uncompressed data.

Windows, via Process Explorer.

 

I get smoother SACD playback by limiting JRiver to 1 CPU core instead of letting it use all four now.

This interferes with other tasks like audio analysis, conversions, and video playback though.

 

In v18 this was not necessary at all. Using the v18 method of memory playback (storing the track in memory instead of decompressing it into memory) and extending that by caching multiple tracks instead of only the currently playing track would be a much better use of memory than the current method.