Print

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

[Bill Kearney]

If I'm down-converting to sync files with a device, how does it calculate the end sizes of the files?

I ask because I've got a number of tracks in 192k, 256 and 320k that when down-converter are absolutely small enough to fit on the device.  In their source size, of course, they wouldn't.  It would appear MC is basing it's calculations on the source sizes.  Is this correct?

Could we have an over-ride that ignores this instead of forcing the removal of what "won't fit"?

[Bill Kearney]

bump?

[Vincent Kars]

As far as I know, JRiver makes an estimate of the converted size.
The play list I use is FLAC, hence it won't fit on the portable but JRiver can cope with this.

I wonder if you might have another problem.
What happens to me quit often is that JRiver won't recognize the files already on the Android phone.
Hence it tries to sync the entire playlist and reports the device to be full/ not big enough.
 

[Bill Kearney]

I'm not dealing with FLAC nor anything already on the device.  Although I do have a few M4A tracks.  I do have some video files and I don't think they're being transcoded.... I'll have to check.

Meanwhile I've just set up a device from a drive letter pointing to a network share.  I then sync to that and manually drag the files over to the portable player. 

The problem is the sync program is being too smart for it's own good.  On one hand it understands the tracks would require more room that fits.  But on the other hand it's ignoring that format conversion has been selected; which will result in smaller (as yet to be computed) sizes. 

I'd like there to be a per-device option to ignore the size of the device.  I could see where this could present a problem in that the sync handler would have to be able to (gracefully) deal with running out of space.  Thus a checkbox that let's me make that call would be nice. 

As for on-device media and its impact, that might be good to bring up in a separate thread. 

I sort of ran into that and kind of asked about it, from a different angle.  Here:
http://yabb.jriver.com/interact/index.php?topic=93196.msg642498#msg642498

I asked about rebuilding a playlist from media that's already on a device, but using tracks from the database (not the on-device ones). 

[Vincent Kars]

Meanwhile I've just set up a device from a drive letter pointing to a network share.

Have you set JRiver to "always concert"

I then sync to that and manually drag the files over to the portable player.

Don't understand the manual part.

[Bill Kearney]

Always convert, you mean?  Yes, for that device it's set to always convert.

The need to manually copy is due to the fact that the sync feature only calculates based on the sizes of the source tracks, not their sizes when converted.  I have a playlist of tracks with varying bitrates.  Their original size is 574mb.  Converted to mono 128k that drops to 221mb, which is just under the 256mb limit of the device.  MC won't sync to the device directly because it thinks 574 won't fit in 256, ignoring that it's also going to be converting them (and making them smaller as a result).  So I just use a network share as a temporary holding place.  MC syncs to it and then I manually drag-and-drop the contents of that share onto the device. 

You can convert video to audio in JRiver currently.  Look in Library Tools --> Convert Format.  There's an option to extract the audio from video.

Ok, that's handy.  It'd be nice if it could do this on-the-fly within the device sync action (which is what I'm asking).  I don't "need" to have both the video and the converted audio kept on MC.  But with a little reorganizing I can probably sort it out.