Print

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

[retro]

Hello..!

I use MC in server/client mode.

On my client, I have ticked Always Convert Audio to PCM 24-bit. My Audiophile ears tell me this sounds better than not converting.
This works fine with 2-ch flac and waw.

But when I play multichannel flacs, they always play at 2-ch with this setting, so then I have to change to Convert Audio When Necessary. Then I get multichannel fine.

Further, when I play SACD ISO's, they don't play at all, so I have to again change to Don't Convert Audio. Then my ISO's play fine, 2-ch and multichannel.

Is this normal behaviour..? Do I really have to change back and forth between these settings or is there something I'm missing..??

[glynor]

The conversion settings are probably set to 2-channel, which is why multichannel flacs don't work.  I don't know if MC handles converting ISO files on-the-fly well, so that may not be possible.  However...

On my client, I have ticked Always Convert Audio to PCM 24-bit. My Audiophile ears tell me this sounds better than not converting.

This makes no sense, and is counter-intuitive.

With this option OFF:
* The MC Server sends the audio files to the client UNALTERED via HTTP.
* The Client decodes them (using the exact same audio engine that the server uses) and sends them to the output device as PCM appropriately.

With this option ON:
* The MC Server decodes the audio files and re-encodes them as PCM (again, using the same audio engine as the client).
* Then it sends these PCM files (much larger than the originals, using FLAC as an example) to the client via HTTP.
* Then the MC Client just handles playing the PCM back.

So, with it on and set to PCM, what you've accomplished is you've moved the necessary PCM decoding step from the client to the server.  Since both the client and the server have identical audio engines, this has only accomplished loading your network with additional data (sending larger pre-decoded PCM files, rather than smaller FLAC files), and you've limited (or made fiddly) your playback capabilities.

The main point of this option is to force the server to encode music to smaller formats (like MP3) to ease streaming in bandwidth-limited environments (like streaming over the Internet, for example).  If you are at home on your LAN, then it makes no sense to pre-convert for another copy of MC.  For DLNA it might be entirely different because the decoding system may be incapable of some formats that MC can decode.  But when using MC talking to another copy of MC, then it makes little sense to pre-convert to PCM.

I think your "audiophile ears" are deceiving you because of (a) the placebo effect and (b) an incorrect assumption about what the option does.

[retro]

With this option ON:
* The MC Server decodes the audio files and re-encodes them as PCM (again, using the same audio engine as the client).
* Then it sends these PCM files (much larger than the originals, using FLAC as an example) to the client via HTTP.
* Then the MC Client just handles playing the PCM back.

Yes, but isn't that why this option was implemented in the first place, for those who believe/hears that waw sounds a tiny bit better than flac..?!?
I am one of those people.. We have tested this (no not blind) and concluded that waw does have a slight edge soundwise compared to flac. And I do prefer this setting on.

[6233638]

The new Memory Playback changes in MC19 are for people who believe in things like WAV sounding better than FLAC, as it forces the entire track to be uncompressed into memory for playback. (all audio is played back as if it were stored in an uncompressed format like WAV/AIFF)

The conversion options are for clients which do not have the CPU power to play the compressed formats locally. (e.g. DST compressed DSD tracks)

[retro]

The conversion options are for clients which do not have the CPU power to play the compressed formats locally.

Then why the option PCM 24-bit..?!?

[6233638]

Then why the option PCM 24-bit..?!?

Uncompressed WAV requires very little CPU power for playback.
DST compressed DSD tracks require a lot of CPU power for playback.

The option is useful if you have a powerful server, but are using low-power devices as a client.

[retro]

Ok, guess I'll have to try memory playback and compare with the current method.

Maybe I will just have to keep switching modes depending on source material..?

Or is it possible to configure zones with different settings like this..? I haven't really gotten into the zones thing yet...

[glynor]

The conversion options are for clients which do not have the CPU power to play the compressed formats locally. (e.g. DST compressed DSD tracks)

That makes sense, and explains the otherwise counter-intuitive PCM options.

[glynor]

Yes, but isn't that why this option was implemented in the first place, for those who believe/hears that waw sounds a tiny bit better than flac..?!?
I am one of those people.. We have tested this (no not blind) and concluded that waw does have a slight edge soundwise compared to flac. And I do prefer this setting on.

Even if you accept that this is true, it makes no sense if:

1. The source is FLAC anyway.  You can't make it mystically more "perfect" when you convert it from FLAC to PCM (which happens somewhere in the chain no matter what for playback).  Once you've "lost" data, you can't regain it.  Now, FLAC does NOT lose data (provably so), but if you assume that everyone who has tested it mathematically is wrong, lying, or missing some important detail... Once the data is gone, you can't get it back.  If you can get it back (you can, that's what FLAC compression does) then you can get it back in the same way every time.  Computers are binary machines.  The answer is either yes, or no, not ever "somewhere in the middle" (assuming you exclude the "maybe they're real" D-Wave machines).

2. Even IF you assume that somehow it has lost data that didn't exist in the first place, changing on which computer PCM conversion happens, if the conversion engine is identical, makes no sense.  For this to be true, the conversion on one machine would have to be different from the conversion on the second machine.  If this is true, then either you are (a) not using the same software engine to do the conversion (not true if the server and client are both MC), or (b) one of your two computers is broken and cannot do math properly, in which case NOTHING it outputs can be trusted (because it will also screw up the reading of the PCM data that comes in from the server).

The DSD performance reason for the option makes sense.  In this case, you will get the same output either way, but a low-powered Ultrabook or Netbook might not be able to handle the conversion, while the Core i5 (or dual Ivy Bridge Xeon) server can handle it.  Everything else is silly and not worth discussing.