Automatic syncing from JRiver to WM1A or similar

What is this all about?

This is a brief info dump about syncing DAPs or external storage with JRiver.

I recently bought a Sony WM1A, and as you probably know, it has 128GB internal storage, and a single card slot. I generally want to carry more music than would fit on a single card, so need to get off my ass and use the internal storage too. However, doing this by hand could get annoying really fast.

My music is stored as FLACs on a NAS. One of the players that uses the files is JRiver running on my PC. JRiver has some rudimentary syncing support, as well as quite useful filtering/expression support. It's possible to set it up so that it reacts to library tags and automatically writes/moves content to the internal rather than external storage, or even to the card of your choice on mounting.

What follows is a quick and dirty explanation of how I set it up, in case someone else wants to do something similar, with a similar bunch of mass storage destinations. It may also help me, when I forget how the hell I did it, which seems likely.


The method
In principle, this should work with most players that mount as mass storage. Here you can see that the F: and G: drives are visible from the WM1A:



That's great, we're in business- we can configure those drives as "handhelds" in JRiver, and set up automatic smart syncing. First of all though, we need to define a new data field in the library, which stores the flag that defines where the content goes.

In Options/Library And Folders/Manage Library Fields, you can define a new field like this:



I used a tickbox and set a single "acceptable value", IsInternal* to make the field function as a simple boolean. That means it's either "on" or "off"- or from JRiver's point of view, the field is set to "IsInternal" or nothing. This is important.

Once you've defined the new field, you can go into tagging view (alt-enter) and if you right click and go to "Also Show" in the popup menu, you can enable the new field. This means that you can easily use this field and tag content that you want to route to the internal storage. To mark content, simply go to the new "Internal" field and tick it like this:



Now we need to define two "smartlists" which automatically react to the presence or otherwise of the new field. I used two, called "Internal Storage" and "External Storage". To set up smartlists, go to "playlists" in the left panel, right click, and choose "add smartlist".




Here's how I set up the first one, which has a smart rule to test for the presence of the "IsInternal" value in the "Internal" field:



...and here's the companion smartlist for the external storage, which tests for the absence of the same value:




You can check that all this is working by tagging a few albums with the new field, and then checking the smartlists. One should consist of tagged content, the other of untagged. If it doesn't there's something amiss, so go back and re-check the config.

For the final lazy bastard convenience step, I set each "handheld" (the F: and G: drives ) up to sync automatically on mounting, and also to delete any content not in the playlist. This is helpful for keeping things sane, but it's worth thinking carefully before enabling this option, if you sometimes use the device for storing other content temporarily (though strictly speaking, JRiver shouldn't touch stuff outside of certain folders like "MUSIC".. in theory). Anyway, this is configured in the options for each handheld.

So, for the internal storage (in my case, the F: drive), I unticked all content in the right pane of the options dialogue, except for the "internal" smartlist. I also enabled the "Auto Sync.." and "Delete from handheld.." options:



Similarly, for the G: drive, I set it up to use the "external" smartlist, with the same options ticked:



Et viola! Now, when the WM1A is plugged in, content automatically flows to the correct bit of storage, easy.


Advanced level laziness:
If you have enough content that you needed loads of cards, you could easily manage it this way, too. Instead of a single acceptable value for the custom field ("IsInternal"), you could have a semicolon-separated list of them, like:

Classical; Classical 2; Jungle; Industrial; Ambient; Spoken Word

Because handhelds use more than just drive letter (or presumably mount point, on Linux, can't be arsed to boot into Linux and start JRiver to check), you can have handheld definitions for any number of external cards, and matching smartlist definitions for them. These could match the values in the example above, to copy content onto the appropriate card whenever it's inserted. This would let you pre-manage your content via tags.

It should work when the media is mounted by whatever means, whether through the player, via card readers or whatever else.



* Yes, I know, that's ugly- you don't have to use that sort of notation, and can use spaces. I'm a nerd, and was thinking variable names when I did it.

 

Notes on automatic transcoding

Revisiting this, because I moved computers and needed to figure out how to configure JRiver again. This is probably more sketchy note form than hand-holding, so buckle up. If something doesn't make sense, please do ask, and I will try to help.

I'm writing this as I figure it out (for the second time, grr). Thus I am making notes for my benefit, but putting them here in case it helps others. We all know that the best way to go is to maintain a lossless library and convert down when/if needed. While that sounds like a lot of work, JRMC can make it really easy for you.

For this, it's best to use AAC generally (in terms of broad support and quality/bitrate tradeoff), as long as you use a good encoder. Currently, the best encoders are still the FhG or Apple encoders. If you're a fundamentalist who wants to use Opus or something, and your devices support it, knock yourself out- maybe the hints here can help a tiny bit.

Essentially, you need to find an encoder that has a command line version for your platform. In my case, this is a setup on my Windows box,so I'm using the QAAC encoder- which is a command line wrapper for the Apple AAC encoder. Find it here:

https://sites.google.com/site/qaacpage/home

Once you've downloaded it, have a go at checking it works. Open a command window, cd to where you put it, and invoke with appropriate switches. Here's a quick test using the appropriate parameters to do the equivalent of "iTunes plus" quality- circa 256Kb/s with a FLAC file that I stuck in there for testing:

Code:

C:\qaac_2.60\x64>qaac64.exe "01 More Beats & Pieces (Daddy Rips It Up Mix (Max Chop)).flac" -v 256 -q2 -o poo.m4a
qaac 2.60, CoreAudioToolbox 7.10.9.0

poo.m4a
AAC-LC Encoder, CVBR 256kbps, Quality 96
[100.0%] 4:05.479/4:05.479 (70.8x), ETA 0:00.000
10825668/10825668 samples processed in 0:03.468
Overall bitrate: 259.319kbps
Optimizing...done

Ok, now I prefer to just build a lossy copy of my music library, which I keep on a separate network share. I have set that up as a "handheld" in JRiver. For now, I am not going to go over every single detail, just the stuff that's tricky to work out . Set up a share or directory to be a Handheld in the usual way- if you're not sure how to do that, check the JRiver Wiki.

First up, in the Handheld's settings, go to "Audio" and "Encoder settings". Set "Mode" to "Specified output format". Set the encoder to "External". Set the encoder settings to something like:

Filename: C:\qaac_2.60\x64\qaac64.exe
Parameters: %IN -v 256 -q2 -o %OUT
Extension: m4a

I ticked all three boxes. Now under "Files, Paths and More", I set "Supported Types" to m4a. Remember to set up the stuff in the right pane- which will let you decide which playlists to use. If you're using smart playlists as above, this is where you can hook into them.

There may be some scope in speeding stuff up by varying the number of simultaneous encodes you run, depending on your specific storage and processing resources. Try somewhere between one and four, and look at the speed that JRiver gives you when you sync. Remember that more is not always better- if you're maxing out network, or causing spinning disks to seek too much, reducing sequential write speeds. You don't actually need to understand all those factors, though- just fiddle with the value and see which gives you the highest sustained speed.

Right, that seems to have been enough for me to get this working myself. I'm sure that I have falling into the "knowledge trap" and glossed over something that people would need. If you're interested in this facility and are stuck on something specific (that you can't find on the JRMC wiki or via Google more generally), do let me know.