Print

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

[MGD_King]

14.0.31 (07/14/2009)
8. NEW: Added option to play files from memory instead of disk which is useful in high-end audiophile environments. (file is loaded in a background thread to system memory (capped at 256 MB) and played from there)

I really like this idea! Can't wait to get home and try it out! 

[Daydream]

I like it too. I wonder if it can be extended for other things within MC - say cache the entire external cover art folder (500MB to 1GB) and use it as priority (instead of cached thumbnails). On a 8GB RAM system, unless I'm firing up Photoshop or the likes, there's lots of RAM that... just consumes electricity .

[AoXoMoXoA]

8. NEW: Added option to play files from memory instead of disk which is useful in high-end audiophile environments. (file is loaded in a background thread to system memory (capped at 256 MB) and played from there)

most excellent  

I had just heard talk of a player that did this (forget what it was called) and it seemed like a great idea.
Although I am uncertain as to whether there is an audible difference, or just placebo, it seems it should be better. I can't wait to try it.

How could you set up a DBT to compare? Two instances of MC perhaps?

[JONCAT]

Never thought you guys would do this, cool though, but I think it's ultimately hocus pocus.

Has anyone ABX'd playback in memory vs. playback with Prime95 and a 4-core analysis of 20K .flac files running?

If the PC introduces that much jitter to the digital output or audible distortion to analog, I fail to see how memory vs. disk affects this. What's the dif. in cpu usage here, psu wattage...?

Maybe I'm wrong, will have to ABX it myself.

Is the usability of MC affected at all by this, or does it just happen in the background.

DC

[benn600]

Could this be useful for reducing constant HDD strain?  I mean streaming a thousand kilobits a second all day long!  I'm tempted to turn it on just because it seems like a good idea.  Most of my FLAC songs are 20 - 50 MB and I doubt any exceed the 256MB limit.  Cool new feature...

When I saw this in the change list I was prepared to scroll down and see a bunch of uproar and praise.  lol

[Frobozz]

Is the reason for playback from memory to reduce potential jitter?  Reduce potential latency glitches?  Reduce HD noise?  It all seems rather strange and doesn't make sense to me given how operating systems work and all of the other stuff that is going on in a computer.  I don't see it being harmful at all to playback, but I'm not understanding what the benefit(s) could be.

[CadErik]

I don't see it being harmful at all to playback, but I'm not understanding what the benefit(s) could be.

Yeah me either - the disk activity to read flac files or any other lossless format should be negligible.

Erik.

[benn600]

Ultimately I think the best solution would be to read everything from solid state, ultra fast memory.  I guess it couldn't hurt!  But like I said, I would consider enabling it all the time just so *any* hard drive wouldn't have to be scanning for data constantly all the time.  It would look between songs every few minutes rather than all the time.

[MGD_King]

In my testing I've discovered that there's not as much hard drive activity lights using this feature, nor is there as much network activity lights on my switch when connected to a media server. While the average user may never realize those little things, I think it makes MC more effecient by reading from memory, especially if MC can load up 3 or 4 lossless files (or a whole album of MP3) ahead of time and read it that way. Think of it as a 256 MB buffer for MC. I think it would be cool to be able to select what size of memory you could use for this feature so if you have 4GB of memory, let MC use 512MB.

[Matt]

The early builds of this features could cause tagging problems.

Information here:
http://yabb.jriver.com/interact/index.php?topic=52955.0

Fix here:
http://yabb.jriver.com/interact/index.php?topic=52956.0

[JONCAT]

Thanks Jim. Now that this feature/method is in our favorite player, it can't hurt to try it. I wasn't about to load some special player to do this.

This has been and will be a very contentious point in hi-fi circles as many believe it is mainly the PSU and excessive activity of the system which can introduce jitter at the source. Engineers like Dan Lavry will say this can be handled in the DAC and others claim otherwise.

You have been warned 

http://www.audiocircle.com/index.php?topic=69397.0

DC

[francisr6]

Hi.

Great feature!, in order to complete this, do you know how we could have a complete playlist or album (the tracks that have to be played) copied from their original path (saying a massive Raid 5 hard disk) to the system disk where MC is installed and then be played from this new path?

Thanks a lot.

[flac.rules]

This has been and will be a very contentious point in hi-fi circles as many believe it is mainly the PSU and excessive activity of the system which can introduce jitter at the source.

DC

Well, to be honest, there is a lot of BS in the hi-fi-circles.. People claiming the strangest things.

[benn600]

I think adding the feature was a good idea.  I just turned it on and instead of seeing network activity of 0.05 to 0.45% the entire duration of the song, I see ~35% for a second and then nothing.  Seems like less wear and tear on hard drives overall.  I only notice about a second delay when loading large 150MB FLAC songs.  Typical 30MB FLAC (average length songs) are apparently instantaneous.  I'll leave it on for a while.

[JONCAT]

Well, to be honest, there is a lot of BS in the hi-fi-circles.. People claiming the strangest things.

AMEN!

[JONCAT]

Well, to be honest, there is a lot of BS in the hi-fi-circles.. People claiming the strangest things.

If you check the thread, I posted an article of a doubleblind study on jitter; very interesting.

DC

[newsposter]

In addition to the internal ram cache, how about supporting the use of any other directly connected device (flash media on usb, a dedicated hard drive, etc, etc) for cache.  This cache could be pre-populated based on selected playlists and would hold all files necessary to the play list (media, cover art, anything else).

Simply supporting devices that are accessed via a LOCAL UNC path would take care of this just fine.

For the sake of performance, MC needs to be smart enough to refuse the use of slow devices, otherwise what's the point??  USB must be v2.0 speeds.  Hard drives CANNOT be the system drive (C:) or the drive that MC itself is installed on.  And so on.  The point of the QuickPlay media is QuickPlay, not just another configuration option for the sake of variety.

As an 'extra', MC could manage a catalog of these cache devices.  Think about creating and maintaining a list of the cache devices (say, thumb drives, CF/SD cards, etc) and what is on them for QuickPlay.  If the library owner updates a playlist, MC would be smart enough to remind the owner that the playlist is also maintained on a cache device and "would you please insert the cache device so I can write these updates to the device".

All it would take would be a signature file unique to each cache device (NOT the volume label, winderzz can screw with that at any time).  The sig file would be nothing more than a media ID key.  It could even be a xero-length file with a unique hashed name.  MC would read it and do what is necessary.

[hit_ny]

Well, to be honest, there is a lot of BS in the hi-fi-circles.. People claiming the strangest things.

..and this is only a ploy at allaying what those that say not many players can do.

Never mind whether you can actually hear a difference 

[JONCAT]

My point, the word I used, was contentious.

This topic falls under wire, vibration isolation, changing out caps, upgrading power supplies, etc. not changing out your speakers or upgrading an amp.

This is ultimately about jitter and many engineers argue you can't introduce more jitter at source. Some argue you can.

At the link I posted above there is one study claiming random jitter below 2ns can't be noticed, but they discuss another study the claims it can be.

This is not a "night and day tweak", it may be useful for multiple reasons but something like moving to a passive preamp would be what you're referring to imo.

to each his/her own,
DC

[JONCAT]

I agree, well said. Rankin's async word clock on usb is pretty hip. The problem I have is that for me, usability is a fundamental aspect of my system which is seeking good fidelity. Approaching diminishing returns, fidelity actually becomes a function of usability....at least for me: I'm not going to manually load single .wav files into Wavelab on my offline, every uneeded background process, pole-pig connected PC in order to squeeze out a nanometer of top end smoothness at 19.9kHz. Now that JRiver has this function, I say great, but I'll be doing a macroscopic study of my seperates (DAC, monoblocks, speakers, etc.) before I find myself ABXing files loaded into memory and vice-versa. At some point, you just have to enjoy the music and leave the neurotic stuff behind.

DC

[flac.rules]

Audio is not magic field, its a scientific field as "everything" else. There have been extensive research and tests on what humans can and cannot hear. A lot of the claims in audio circles have failed again and again in listening tests. <it might be your system, but more often than not it some crazy claim with no base in reality.

[Frobozz]

This isn't the place to argue about whether various audiophile tweaks are audible or make a difference.  There are plenty of audiophile forums where you can have those kinds of often divisive discussions.

I'm happy to see JRiver implement various audiophile options even if they are things that I am not going to use.  Some may seem silly to me while others could prove useful to me.  As long as they follow a philosophy of do no harm then I don't see a problem with it.  If a feature is scratching an itch for one of the developers to try something, that's all good.

Keep in mind that useful features like ASIO, WASAPI, and true gapless playback are examples of what could be called audiophile features, and those features are very useful to me.  Exploring new audiophile features and improving on the existing ones is beneficial.  If those new features attract new audiophile users to JRiver, all the better.

[666JackTheKnife666]

Most of my Audio is Audio books and the files are huge. is there anyway to increase the memory beyond 256meg ? would love to set it up for 2gb or more of ram.

[Pjotr]

From the audio viewpoint there is no advantage. Data must be buffered in memory anyway --> Flac files, mp3 and other formats need to be decoded anyway before it can be send to the audio card.

The only advantage is for disk/network load. I also use my media player to play regular CD’s: Those silvery shiny disk you know It would be nice if a whole CD can be captured at once with re-reads when errors are detected and buffered to memory.

<Edit>

Just tested it. Big advantage: Over WLAN no interruptions anymore due to the key exchange of WPA2

Question: If you make the buffer this long, why not make it sizable depending of the amount of memory available, so a whole album can be read at once to memory?

[Pjotr]

I don’t want to go in a lengthy audiop(h)ile discussion but as long as the PCM data is correctly delivered to the DA converter chip it doesn’t matter how it is delivered to the DA chip. And I don’t see why a conventional computer with decent media software like MC cannot do that. Reading the stored data from HD, an USB stick, over a network or from internal ram doesn’t matter at all then.

Provided the PCM data is delivered error free at the DA chip, what counts from a sonic viewpoint is de quality of the DA chip and  analogue circuitry thereafter and the clock circuitry driving the DA chip.

If you want top notch audio (as I do), hook up a high quality USB / FW DAC to your PC. But many semi pro PCI cards a very  good also.

[newsposter]

just a thought...

"Play from memory" would be extremely useful in an embedded application such as the MC appliance we keep reading hints about.

Load XP Embedded and MC onto a flash card or DoM (don't even need a fancy/expensive SSD) and boot from there.

The MC library data (media) is kept on a different piece of flash media, also very inexpensive.

When XP Embedded boots up and MC starts, the media that is nominally stored on that second piece of flash is copied into system ram for playback.

Considering that an SSD is $300- and a pair of 512 Mb DoMs is less than $50-, this would really affect the delivered price of an appliance.

JR could even sell the pair of DoMs as an unsupported DIY package.  Say 3x or 4x the nominal hardware cost.  Set up XP Embedded to do some serious hardware checking as a QA kind of thing, but it's very do-able.

XPE has a few cheesy encryption options (or just use TrueCrypt) that would provide some basic copy-protection for the OS and MC.

In my mind (and assuming the devs have at least a passing familiarity with XP Embedded), this is about a weeks effort to prototype, another month for QA and two weeks to set up an encryption scheme for the boot DoM.

Or, see if MC can be made to run under something like TinyCore Linux and the current version of Wine.  No MSFT distro license costs there.

[JimH]

news,
Thanks for the suggestion.

Jim

[Pjotr]

I don’t know if this is a real issue but regular HDD are not well optimised for streaming. For streaming purposes with media boxes there are special designed HDD on the market. So from this viewpoint, moving as most as possible at once in ram from the HDD will be beneficial with regular HDD.

Any thoughts about this?

[jamesecox50]

Yeah me either - the disk activity to read flac files or any other lossless format should be negligible.

Erik.

Old post but it made a diff on my system, I used SSD drives and when I went to spinning external disks I had noticable degradation. I actually did blind tests with listeners.  The drive was a WD myBook.