Print

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

[Fitzcaraldo215]

Testing.

It is a rainy Sunday with no football.  My amazing Eagles won it all!!  Here is a test of channel alignment in JRiver. I hope you find it useful.  This picks up on the earlier thread "Request Change in the Handling of Multichannel". But, I am merely trying to clarify what is going on under controlled circumstances of a specific test.  I am not recommending for or against a change to how JR handles the issue, which, either way, might have consequences for existing users.

System: PC Win7 Pro, JRiver 23.0.100 (32-bit),  Exasound ASIO driver to Exasound E28 DAC via USB.  Dirac Live and JR Bass Management in Room Correction,  which I normally use,  were bypassed for the testing to avoid any possible conflict.

Observations of 8 channel instaneous output level display using the Exasound driver, as follows:

SACD/DSF file with 5 channel input using 5.1 output:

  - signal present in FL, FR, C, SL, SR, but none in sub channel.  Back channels were silent.  All correct. 

SACD/DSF file  with 5 channel input using Source Number of Channels output:

   - signal present in FL, FR, C, Sub, SL, but none in SR!!!  Back channels were silent. Incorrect alignment!!!

SACD/DSF file with 6 channel input using 5.1 output:

  - signal present in FL, FR, C, SL, SR and .1 sub channels, as expected.  No signal in Back channels. Correct.

SACD/DSF file with 6 channel input using Source Number of Channels output:

  - same as above. Correct.

SACD/DSF file with 6 channel input using 7.1 output:

- same as above, but now with signal in Back Channels, as expected. Correct.


Note that the driver level displays do not indicate anything about signal frequency response, just instantaneous signal level by channel.  So, it is not readily apparent if the LFE input signal is present in a given output channel.  But, the absence of any signal in the .1 sub output channel or any other channel is clearly shown by the display.  However, there is also no bass management in the test setup which would redirect bass frequencies or sum them from other channels to the .1 sub channel.

The 5 channel DSF file used for testing was:

Bach: Brandenburg Concertos/Richard Egarr/Academy of Ancient Music (Harmonia Mundi)

The 6 channel DSF file used for testing was:

Adams: Harmonielehre & Sort Ride in a Fast Machine/MT Thomas/San Francisco Symphony (SFS Media)

Results were retested with other random files of each channel count and yielded the same results consistently.

--------------

My conclusion is that JR appears to map these SACD/DSF files to the proper channels in this Mch setup, except for 5-channel files when using Source Number of Channels as the output parameter.  There, it appears to misdirect SL into the sub .1 output and to move the SR input to SL.

On the other hand, use of 5.1 or 7.1 as output parameters always works as expected.

[RD James]

My conclusion is that JR appears to map these SACD/DSF files to the proper channels in this Mch setup, except for 5-channel files when using Source Number of Channels as the output parameter.  There, it appears to misdirect SL into the sub .1 output and to move the SR input to SL.

You explicitly told Media Center to not remap the channels by selecting "source number of channels" in DSP Studio.
When you do that, it is the playback device's job to handle channel mapping.
Your Exasound DAC evidently does not do any channel mapping itself - which is true for most if not all DACs.
 
The channels are not being mapped correctly because you turned that feature off.

[Fitzcaraldo215]

You explicitly told Media Center to not remap the channels by selecting "source number of channels" in DSP Studio.
When you do that, it is the playback device's job to handle channel mapping.
Your Exasound DAC evidently does not do any channel mapping itself - which is true for most if not all DACs.
 
The channels are not being mapped correctly because you turned that feature off.

OK, OK, OK.  We had this discussion in the other thread.  And, I am a fan of JRiver as much as you.

So, where does it say I turned a needed channel mapping feature off if I selected Source Number of Channels?  Answer:  it does not.  So, as a result, people choose Source Number of Channels whether they understand that or not.  And, a number of those people are unhappy with the results, which they were never told about.

I have my own workaround, which works perfectly for me.  So, I am good.  It is just a question of whether other users, both past and current, will get a result they do not expect because they were lulled into believing Source Number of Channels was the right choice.

[RD James]

I thought it was self-evident. With a 5-channel source, when you select "source number of channels" you get a 5-channel output.

The standard 5.1 channel layout is:
1 - Left
2 - Right
3 - Center
4 - LFE
5 - Rear Left
6 - Rear Right

So if we place a 5-channel signal into that layout, it is mapped accordingly:

(Audacity's channel mixing options used for illustration)
 
To map a 5.0 signal to a 5.1 device, you need a 6-channel (5.1) output:

 
"Source Number of Channels" is for devices like AVRs and Sound Cards which see a 5-channel input and remap it to 5.1 themselves.
Most (if not all) DACs are 'dumb' devices that play what you give them without doing any remapping.
Fortunately Media Center can do the remapping itself, if you select a 5.1 output.
 
Of course that conflicts if you intentionally want to output a 2-channel signal with a stereo source, but:
a) Most people using a DAC have no need for such an option, since the DAC won't be doing additional processing.
b) It sounds like Hendrik is going to add an option which remaps multichannel sources, but outputs a 2-channel signal for stereo sources.

[Fitzcaraldo215]

The only problem may be that the top of the selection list upon opening that list of output parameters is Source Number of Channels.  It is a seemingly logical choice, a seductively easy one.  If you think it should be self evident that it is not going to handle 5.0 media correctly, I don't think your logic adds up. It does not. There is no indication anywhere that it does handle 5.0.  But, if you insist that it is our problem and we are idiots, what can I say?

[RD James]

The only problem may be that the top of the selection list upon opening that list of output parameters is Source Number of Channels.  It is a seemingly logical choice, a seductively easy one.  If you think it should be self evident that it is not going to handle 5.0 media correctly, I don't think your logic adds up. It does not. There is no indication anywhere that it does handle 5.0.  But, if you insist that it is our problem and we are idiots, what can I say?

Your playback device does not handle 5.0 signals correctly. Media Center does.
When you tell Media Center to remap a 5.0 signal to another channel format; e.g. 5.1, it does this correctly. Your own tests confirm this.

You are complaining that Media Center doesn't remap 5-channel signals when you tell it not to.
It can't map Rear-Left to Channel 5 and Rear-Right to Channel 6 when you tell it to output 5.0 as a 5-channel signal. Channel 6 doesn't exist.

[dtc]

It seems that the real problem here is that there is no way to know whether or not the input file has a LFE channel. 6 channel can be 6.0 or 5.1, 5 channel can be 5.0 or 4.1 etc. MC has to decide one way to interpret each number of channels. With 6 channel it is pretty easy, since almost all 6 channel files have an LFE channel. The problem is with the unusual files like 5 channel. Neither 5.0 or 4.1 is a dominate format so MC does not know which output format to use. 

To make Source Number of Channels work in all cases, MC would need to know if an LFE is present or not. Unfortunately, the standard tags do not identify if there is an LFE present or not. So, MC has to choose one option and use that every time.  An LFE tag would allow MC to choose the right option, but it would an a non-standard process.

One solution would be to adopt a standard that any files without a LFE channel be put into the next higher level number of channels with a blank LFE. So, for example, 4.0 would be put into a 5 channel file, with the LFE blank.

[RoderickGI]

Yes, I found that useful.

But I think RD James' response is correct. Your results are what I expected.

I don't think anybody is calling anybody else an idiot. Don't take the emphasis used as saying so. Writing style. Cultural differences. All that. I think understanding the software is what the forum is all about, as at this level of detail the documentation isn't very good. Although there is some indication of what to expect in the Wiki article: https://wiki.jriver.com/index.php/Mixing

I'm not sure what the best approach is to these files. Hopefully, Hendrik can come up with a good solution. But the perfect solution would involve even more complex configuration of MC, probably with a file-based key (tag) to which configuration is used, which could open another can of worms.

[RD James]

I don't think anybody is calling anybody else an idiot. Don't take the emphasis used as saying so. Writing style. Cultural differences. All that.

Yes, that's not my intention. If it comes across that way, I'm just frustrated at having these circular discussions over the course of several days now.

It seems that the real problem here is that there is no way to know whether or not the input file has a LFE channel. 6 channel can be 6.0 or 5.1, 5 channel can be 5.0 or 4.1 etc. MC has to decide one way to interpret each number of channels. With 6 channel it is pretty easy, since almost all 6 channel files have an LFE channel. The problem is with the unusual files like 5 channel. Neither 5.0 or 4.1 is a dominate format so MC does not know which output format to use.

With the exception of 5-channel SACDs, or 4-channel quadrophonic tracks, I can't recall encountering unusual formats like 3.1 or 4.1 which have not been stored in a container format. So 4.1 would be contained in a 5.1 signal with an empty center channel for example.
 
I think it could be useful if there was a tag which would let you assign explicit channel mapping to unusual files.
I do have a handful of files where the channels are mapped wrongly - in the file itself - and there's no easy way to fix it automatically since it's a compressed format like DTS.

To make Source Number of Channels work in all cases, MC would need to know if an LFE is present or not.

This still misunderstands what "source number of channels" is doing.
If you give it a 3 channel input, you get a 3 channel output. Give it a 24 channel input and you'll get 24 channel output etc.
Media Center doesn't need to know anything because you are essentially bypassing all of Media Center's mixing features, and passing that task onto the playback device.

[dtc]

This still misunderstands what "source number of channels" is doing.
If you give it a 3 channel input, you get a 3 channel output. Give it a 24 channel input and you'll get 24 channel output etc.
Media Center doesn't need to know anything because you are essentially bypassing all of Media Center's mixing features, and passing that task onto the playback device.

Yes,  Source Number of Channels simply copies the input channels into the output channels. Unfortunately, that is sometimes not adequate because MC has no way of knowing the input format. The non LFE formats are non standard, but they exist and it would be nice to find a way for MC to handle them easily.

The idea is for Source Number of Channels be augmented somehow (like a tag) so that it can output the right number of channels with the correct mapping from the original file. It does not do that now, and has no way to do it since it does not know the input format.

The problem with setting a particular output format like 5.1, is that is applies to all files, not just specific ones. That is undesirable for reasons that have already been discussed, like applying dsps to 2.0 files that are turned into 5.1 by MC and the limitations of zone switch in playlists.  And it still cannot differentiate between 3.1 and 4.0

Also, the idea that a receiver is all powerful in re-mapping is not really true. Receivers typically cannot handle the task of differentiating a 3.1 and a 4.0 signal on the fly any better than MC can.

It seems like there are two options - either provide some way through tags to specify the channel mapping in a tag or to state as a restriction that all files conform to a specific LF, RF, C, LFE, SR, SL, BR, BL etc. format. 

The latter is the easiest, but then you need a tool to convert non-standard files into the standard format.  That would be pretty easy for one format, like flac files, but becomes a little daunting for a large number of formats.  DAWs often have this capability but it would be nice to have an open source utility to do this. dBpoweramp has a utility to output each channel as a separate file, but I am not sure how to merge them back together in a different order.  It does look like FFmpeg can rearrange channels, although I do not know the details.

https://trac.ffmpeg.org/wiki/AudioChannelManipulation


For a generalized solution, Microsoft has actually addressed this issue in Windows with a WAVEFORMATEXTENSIBLE data structure which has a dwChannelMask code for each channel. Note that the codes do not conform to a standard 7.1 format, since the 7/8 channels are Front Left of Center and Front Right of Center.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd390971(v=vs.85).aspx

To follow that approach within MC would just mean that each file have an appropriate bitmask set in a tag. I suppose if the bitmask is 0, then no mapping is done and then there could be a bitmask function which just had a list like the Microsoft one and you could specify the appropriate boxes in order and the function would create the appropriate bitmask.

I do not know of a comparable id3 tag mapping process, but maybe there is one.  Anyway, if the mapping were internal to MC then it does not really matter if it is a standard table or not.

[RD James]

Yes,  Source Number of Channels simply copies the input channels into the output channels. Unfortunately, that is sometimes not adequate because MC has no way of knowing the input format. The non LFE formats are non standard, but they exist and it would be nice to find a way for MC to handle them easily.

But Media Center doesn't need to know anything for "source number of channels". It is passing through the audio data to your playback device.
Your playback device is the thing that handles all channel mapping when you use "source number of channels".

Media Center only does any mixing when you select a format like 5.1 or 7.1
"Source number of channels" is telling Media Center: "do no mixing".

The idea is for Source Number of Channels be augmented somehow (like a tag) so that it can output the right number of channels with the correct mapping from the original file.

Then that's not the source number of channels.
If you take a 5.0 input and map it to a 5.1 output, you have increased the number of channels from 5 to 6.

The problem with setting a particular output format like 5.1, is that is applies to all files, not just specific ones. That is undesirable for reasons that have already been discussed, like applying dsps to 2.0 files that are turned into 5.1 by MC and the limitations of zone switch in playlists.  And it still cannot differentiate between 3.1 and 4.0

Can you upload an example or point to a source which is a 3.1 audio stored in a 4-channel container, that Media Center gets wrong?
It's not that I don't believe it can exist, I have just never encountered such a thing.

I think that an "output stereo signals as 2-channel" toggle below the mixing options is the most realistic solution to this problem.
Then you can select whatever channel format your device requires - like 5.1 or 7.1 - but stereo files are passed through for your AVR to apply its own DSP.

Also, the idea that a receiver is all powerful in re-mapping is not really true. Receivers typically cannot handle the task of differentiating a 3.1 and a 4.0 signal on the fly any better than MC can.

I never said that they were. I said that when you select "source number of channels" you are passing that task onto the playback device.
Whether your playback device handles that correctly or not, is up to it.
If you want Media Center to do mixing, you have to tell it to do that by selecting a channel format to mix to.

It seems like there are two options - either provide some way through tags to specify the channel mapping in a tag or to state as a restriction that all files conform to a specific LF, RF, C, LFE, SR, SL, BR, BL etc. format. 

The latter is the easiest, but then you need a tool to convert non-standard files into the standard format.  That would be pretty easy for one format, like flac files, but becomes a little daunting for a large number of formats.  DAWs often have this capability but it would be nice to have an open source utility to do this. dBpoweramp has a utility to output each channel as a separate file, but I am not sure how to merge them back together in a different order.  It does look like FFmeg can rearrange channels, although I do not know the details.

https://trac.ffmpeg.org/wiki/AudioChannelManipulation


For a generalized solution, Microsoft has actually addressed this issue in Windows with a WAVEFORMATEXTENSIBLE data structure which has a dwChannelMask code for each channel. Note that the codes do not conform to a standard 7.1 format, since the 7/8 channels are Front Left of Center and Front Right of Center.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd390971(v=vs.85).aspx

To follow that approach within MC would just mean that each file have an appropriate bitmask set in a tag. I suppose if the bitmask is 0, then no mapping is done and then there could be a bitmask function which just had a list like the Microsoft one and you could specify the appropriate boxes in order and the function would create the appropriate bitmask.

I do not know of a comparable id3 tag mapping process, but maybe there is one.  Anyway, if the mapping were internal to MC then it does not really matter if it is a standard table or not.

I don't think it would be especially difficult for Media Center to support custom channel mapping via tags.
As I envision it, when you edit this tag it would present a list such as:

1: 1
2: 2
3: 3
4: 4
5: 5
6: 6
7:
8:
9:
etc.

Then you could simply edit that to read:

1: 1
2: 2
3: 3
4: 4
5: 6
6: 5
7:
8:
9:
etc.

This example would flip the left/right rear channels around, if the file was encoded with them reversed for example.

FFMPEG's channel layout format could also work, though that seems more complicated for people to change.
In that case, you would change: "FL+FR+FC+LFE+BL+BR" to: "FL+FR+FC+LFE+BR+BL"

[tbng]

Having started the previous discussion on multi-channel vs. two-channel, I am most interested in what I read in this new stream.

You have answered a question as to why, on some occasions, one of my rear channels is dead when playing back a multi-channel recording.  Apparently, it is now incumbent upon the user not only to pre-define two and 5.1 channel zones, but also a 5.0 zone, and requires the user know the content of the recording prior to selecting the desired playback zone.  The channel number is in the metadata and listed in TAG, but to the best of my knowledge, that data is not available on JRemote, which is what I use for playback.  (BTW, the 4.0 recordings I have - all from Pentatone - use a 5.0 package with the center channel empty of data.)  I have not delved into JRiver's zone switch which appears to be a possible solution to auto-selecting the desired output zone.  I will try to do so and get back.

I appreciate JRiver looking into this when much of the music server world (for lack of a better term) seems mired in two channels.  (HDTracks current policy, for example, is not to offer multi-channel records for sale - there are a growing number sites that do - and Bryston's digital music player appear to only support two channels - although the newer SP3 may.)  I suspect this has mostly to do with the world's sad disinterest in classical music where hall ambience and antiphonal sounds are vital aspects of playback, two factors of little interest to most pop music fans.

[tbng]

Having just written the previous, I now realize there is no 5.0 channel selection possible in JRiver.

[Fitzcaraldo215]

Again, I have no skin in the game as to what should be done. I am perfectly content with my Zoneswitch between 5.1 and 7.1 zones, plus the checkbox for Play Stereo Sources as 2.1 in each zone. It touches all the bases for me. I am unlikely to change this even if something new is devised.

But, in case there was any doubt, I merely wanted do demonstrate what actually has been happening with SACDs, which include 5-channel 5.0 as part of the Scarlet Book standard, as well as 6-channel 5.1, either at the disk author's option.  5.0 SACDs are quite common in my 4,000+ disc library, as are 5.1s.

I really do not know what happens with BD and DVD files.  AFAIK, all those I have contain a .1 channel, unless they are 2.0, so they all would be mapping correctly even if using Source Number of Channels.

I do observe that many, including Kal and others as well as me, have at one time  "expected" Source Number of Channels to be the proper choice, when it does not actually function as we expected with 5-channel files. That mismatch may also be hard to notice in just listening.  Bass management might obscure it, and a swapped SR for SL plus a dead SR surround channel might not be obvious.  Is it just a poor recording, maybe? 

It might be said by others that our expectations for Source Number of Channels were unwarranted and that it is handling the issue absolutely correctly. However, I think any proposed solution should include a warning to the user that Source Number of Channels might give an undesired channel output configuration, so as to better inform their expectations and keep them out of potential trouble.  I know to avoid it, of course, but others may not.

[dtc]

RD James - I know exactly what Source Number of Channels does. I am suggesting that it could be augmented (changed, improved) to include a new functionality. If you think the augmented version should be called something different, that is fine - Perhaps add an option like "Use Channel Mapping" or something like that. The idea is to add a new functionality. And, yes, that might change the number of channels.

The receiver comment was a general comment, because, in other places in these threads, the comment was made that DACs could not map files, but receivers could. I just wanted to point out that receivers had the same problem.  Did not mean to imply that you said that. Sorry.

Your example of a list is just what I described as a matching function for creating a bitmask.

I think we are in total agreement on these issues.


As to the 4.0 example, the problem is not with with 3.1 audio in a 4 channel file, but with  4.0 audio in the 4 channel file or 5.0 audio in a 5 channel file, or 6.0 audio in a 6 channel file. To play those correctly, the number of channels needs to be increased and a empty LFE channel inserted.

[Fitzcaraldo215]

Having started the previous discussion on multi-channel vs. two-channel, I am most interested in what I read in this new stream.

You have answered a question as to why, on some occasions, one of my rear channels is dead when playing back a multi-channel recording.  Apparently, it is now incumbent upon the user not only to pre-define two and 5.1 channel zones, but also a 5.0 zone, and requires the user know the content of the recording prior to selecting the desired playback zone.  The channel number is in the metadata and listed in TAG, but to the best of my knowledge, that data is not available on JRemote, which is what I use for playback.  (BTW, the 4.0 recordings I have - all from Pentatone - use a 5.0 package with the center channel empty of data.)  I have not delved into JRiver's zone switch which appears to be a possible solution to auto-selecting the desired output zone.  I will try to do so and get back.

I appreciate JRiver looking into this when much of the music server world (for lack of a better term) seems mired in two channels.  (HDTracks current policy, for example, is not to offer multi-channel records for sale - there are a growing number sites that do - and Bryston's digital music player appear to only support two channels - although the newer SP3 may.)  I suspect this has mostly to do with the world's sad disinterest in classical music where hall ambience and antiphonal sounds are vital aspects of playback, two factors of little interest to most pop music fans.

I don't think JRemote is an issue in this, although it allows for manual selection of zones.  I have not tested it, but I believe Zoneswitch rules on the server would override.  I also do not think a zone is actually changed until playback is paused or stopped.

Also, the 5.1 Channel zone handles both 5 and 6 channel SACDs properly.  For me, it also handles 2.0 sources, playing them as 2.1, which is what I want using bass management in JRiver.

I only use two zones - 5.1 and 7.1 - because I do not want 5.0/.1 material played with expansion to 7.1.  If I only had a 5.1 system, I would need just the 5.1 zone and no Zoneswitch.

[tbng]

"I don't think JRemote is an issue in this."

False!  I am frustrated with this lengthy conversation continuously reverting back to the contention of JRiver not being the problem when it is the ONLY music source I have that may not properly play multi-channel source material (or even two-channel material as I want it), much less do it without manual intervention.  I only have to press PLAY on an SACD/DVD/CD player or a television to get exactly what I want without manually intervening, even sequentially mixing recordings with a varying number of output channels.  From a purely conceptual point of view, it poses a question as to why JRiver must be the odd man out on this.  If digital music players are the wave of the future (and they are), then they must start out by doing what their ancestors have functionally accomplished so easily.

I do believe that digital music playback to this point has largely dwelled in a two-channel world and that multi-channel has not been thoroughly addressed, not only here, but everywhere.  Nonetheless, I find it difficult to believe this is the insurmountable problem that some have portrayed here.  Moreover, I would like to hear from JRiver on this subject and further ask that they formally address the problem.

[mattkhan]

I have not tested it, but I believe Zoneswitch rules on the server would override. 

zoneswitch rules do override manual "play to zone" selections

[RoderickGI]

contention of JRiver not being the problem when it is the ONLY music source I have that may not properly play multi-channel source material

multi-channel has not been thoroughly addressed, not only here, but everywhere.

Well, those two statements don't seem very consistent. Which is it, only MC fails, or it hasn't been thoroughly addressed anywhere? I also find it very hard to believe that a TV will correctly play these rare formats such as 5.0 audio in a 5 channel file. The same for a DVD and CD, although a SACD player may get it right since it is designed for such sources. No need to answer, just please remain consistent and focused on forming a proposal that JRiver could implement. If a decent proposal is formed that doesn't break other functionality and addresses the issue discussed here, I'm sure JRiver will consider it.

JRiver are listening. They don't have to be involved in the detailed discussion. Keep it positive though or it will probably just be ignored.

(or even two-channel material as I want it)

I believe that is a separate issue. Now that this thread is specifically addressing the channel mapping issue, which sort of muddied your original thread, please take the "Can't play stereo" issue back to your original thread.

Thanks.

[kr4]

Also, the 5.1 Channel zone handles both 5 and 6 channel SACDs properly.  For me, it also handles 2.0 sources, playing them as 2.1, which is what I want using bass management in JRiver.

It also handles 3.0 and 4.0 sources.

[RD James]

RD James - I know exactly what Source Number of Channels does. I am suggesting that it could be augmented (changed, improved) to include a new functionality. If you think the augmented version should be called something different, that is fine - Perhaps add an option like "Use Channel Mapping" or something like that. The idea is to add a new functionality. And, yes, that might change the number of channels.

The receiver comment was a general comment, because, in other places in these threads, the comment was made that DACs could not map files, but receivers could. I just wanted to point out that receivers had the same problem.  Did not mean to imply that you said that. Sorry.

Your example of a list is just what I described as a matching function for creating a bitmask.
I think we are in total agreement on these issues.

As to the 4.0 example, the problem is not with with 3.1 audio in a 4 channel file, but with  4.0 audio in the 4 channel file or 5.0 audio in a 5 channel file, or 6.0 audio in a 6 channel file. To play those correctly, the number of channels needs to be increased and a empty LFE channel inserted.

Something must be getting lost in translation here, because as far as I can tell you are saying that you:

• Want to use "source number of channels" as your output.
• But "source number of channels" should mix uncommon formats like 4.0 or 5.0 into a 5.1 container (output 4 or 5 channel source as a 6 channel signal).
• You don't want to select "5.1 channels" as your output, despite that being the option to mix everything into a 5.1 container.

If Hendrik can add an "output stereo sources as a 2-channel signal" option that is separate from the main channel selection, I think it would solve everyone's problem with channel mapping for unusual formats - except for tbng because there seems to be something up with their Meridian HD621 which is not switching between 2ch and 6ch correctly.

I think that tag-based channel remapping has some potential uses, but it would not be for general remapping of all 4.0 or 5.0 signals to 5.1 or anything like that. Media Center's "5.1 channel" output already does that.
Tag-based remapping would be to fix sources that have the channels encoded incorrectly, and I think I only have two or maybe three examples of that in my entire library.
 
Better documentation may have helped with this, but even though I have explained it several times, there are multiple people still saying that their expectation with "source number of channels" was that it would mix it to a 5.1 output.
I just don't see how it could be any more clear that "source number of channels" means 4ch in = 4ch out. 5ch in = 5ch out etc.
Why would anyone expect that to be 4ch in = 6ch out, 5ch in = 6ch out etc.

[dtc]

RD James - Let me try once more.

I am suggesting that Source Number of Channels should be AUGMENTED to include the capability to accept a 4.0 input and output it in a 5.1 wrapper with no LFE.   I have used the word AUGMENTED on purpose. It means "to make greater, larger or more compete".  I fully understand that the current version does not work that way. I am suggesting a change to the current functionality to make that happen without having to specify one single output format.

The idea is to have one option (call it whatever you want to) that just works for all formats.  Lets call it "It Just Works" for now.   It could be a new option in addition to Source Number of Channels, although I would argue if It Just Works were implemented then Source Numbers of channels might not be needed.  It Just Works could be a special option that requires an additional tag. As I said before, that special tag may be as simple as whether there is an LFE channel or not.  A value of 0 or blank could mean LFE is present in the input file, so by default it would work just like Source Number of Channels. A value of 1 would mean no LFE and evoke the special mapping.  The more complicated tag option would lay out the exact output channel format, but LFE seems like it should cover anything other than very custom or incorrect file layouts.  Maybe a 2 in LFE could point to the additional full layout tag.

So the options would be

Source Number of Channels - Outputs same number of channels as are input
It Just Works (requires LFE tag for special mapping) - Outputs appropriate number of channels to accommodate specific input file format
1.0 (Mono)
2.0 (Stereo)
etc.

If 5.1 output is used for everything, 7.1 will be truncated and 3.1 will have extra channels added.  If you try to use Zoneswitch for each format, it does not work in playlists.  And, I believe, you still have problems with 4.0, 5.0 and 6.0 files mapping to the right channels.

As to 4.0 files (LF, RF, LS, RS), if you specify 5.1 output, you would like to get LF,RF, C (empty), LS, RS, LFE (empty). However, I believe you get LF, RF, C, LFE, LS (empty), RS (empty).   Maybe I am thick on that one, but just what do you think currently happens with Source Number of Channels for a 4.0 input file output in a 5.1 output?  The current logic just cannot separate a 3.1 input format from a 4.0 input format. As long as there is one and only one mapping to a 5.1 output file, one of them will not faithfully reproduce the input channels.

Honestly, 4.0, 5.0, 6.0 files are rare enough that they might just be ignored with a footnote that says they do not map correctly and suggesting changing them to new containers. But, for a complete solution, some would need to be changed to make them work seamlessly.

[tbng]

I'm with you, although I don't care how JRiver implements it as long as I can just press PLAY and get the correct output every time.

5.0 is not the rare format you claim - at least in the classical recording world.  Every multi-channel file I have downloaded in recent years from DaCapo, NativeDSD, Chandos, Channel Classics, LSO Live, Coviello, CPO, BIS, Florilegium, and Pentatone (and I know I'm forgetting a few labels) have been in that format.  Even Telarc released some of its last SACDs in 5.0.  I have more than a hundred recordings in the format, and the collection will continue to grow, so let's give it due attention here.

[RD James]

RD James - Let me try once more.
I am suggesting that Source Number of Channels should be AUGMENTED to include the capability to accept a 4.0 input and output it in a 5.1 wrapper with no LFE.   I have used the word AUGMENTED on purpose. It means "to make greater, larger or more compete".  I fully understand that the current version does not work that way. I am suggesting a change to the current functionality to make that happen without having to specify one single output format.

The idea is to have one option (call it whatever you want to) that just works for all formats.
 

But that's literally what specifying that you are playing to a 5.1 or 7.1 device does.
 
The only exception is for people using AVRs that cannot detect a stereo signal inside a multichannel container, who want to use the AVR's own processing to upmix stereo to 5.1/7.1, rather than having Media Center do it.
For those people, the proposed "Output mono/stereo files as a 2ch signal" option below the channel selection would fix that.

If 5.1 output is used for everything, 7.1 will be truncated and 3.1 will have extra channels added.  If you try to use Zoneswitch for each format, it does not work in playlists.  And, I believe, you still have problems with 4.0, 5.0 and 6.0 files mapping to the right channels.

You would select a 7.1 output if you have 7.1 playback device.
There's no need to use ZoneSwitch.

As to 4.0 files (LF, RF, LS, RS), if you specify 5.1 output, you would like to get LF,RF, C (empty), LS, RS, LFE (empty). However, I believe you get LF, RF, C, LFE, LS (empty), RS (empty).

If you select a 5.1 output, a 4.0 input plays sound to Front Left/Right and Rear Left/Right. Center/LFE are empty.
Same applies to 7.1, you just have another two empty channels.

The only time that a 4.0 file plays audio in the Center/LFE channels is when you send a 4ch signal (by selecting "source channels") to a device which does not support the correct channel mapping for a 4ch input.
That won't happen if you specify the correct number of channels for your device in Media Center, as it will handle the channel mapping instead of the playback device.

Maybe I am thick on that one, but just what do you think currently happens with Source Number of Channels for a 4.0 input file output in a 5.1 output?

That's not an option which exists in Media Center.
Source number of channels means that number of channels in = number of channels out.
4ch in = 4ch out. I don't know why people find that difficult.

You don't get 6ch out with "source number of channels" unless you are playing a 6ch source.
If you want a 6ch output with a 4ch input, you must specify that you want a 6ch output. That is "5.1 channels", not "source channels".

The current logic just cannot separate a 3.1 input format from a 4.0 input format. As long as there is one and only one mapping to a 5.1 output file, one of them will not faithfully reproduce the input channels.

I've asked this before, but I will ask it again: do you have any 3.1 files which are stored within a 4ch container?
I have a handful of discs with 3.1 tracks, but they are all stored inside 6ch containers.
I have 3ch tracks which contain 3.0 audio, and 3ch tracks which contain 2.1 audio, and they both play correctly when I select a 5.1 or 7.1 output.
3.0 plays to Left/Right/Center, and 2.1 plays to Left/Right/LFE.

Honestly, 4.0, 5.0, 6.0 files are rare enough that they might just be ignored with a footnote that says they do not map correctly and suggesting changing them to new containers. But, for a complete solution, some would need to be changed to make them work seamlessly.

But Media Center does handle the channel mapping for these files correctly.

[dtc]

If you input a 4 Channel File with 3.1 audio in Source Number of Channels, what does it output for 5.1?

If you input a 4 Channel File with 4.0 audio in Source Number of Channels, what does it output for 5.1 output?

How does Source Number of Files know the difference between a 4.0 input and a 3.1 input?

Are you saying it handles both correctly? If so, how does it know what to do with the 2 different 4 channel inputs.


You say "I have 3ch tracks which contain 3.0 audio, and 3ch tracks which contain 2.1 audio, and they both play correctly when I select a 5.1 or 7.1 output. 3.0 plays to Left/Right/Center, and 2.1 plays to Left/Right/LFE"

How does MC do that? It must know that one has a Center and one has a LFE?


If you put a 5.1 input file into a 7.1 output file, you have the same issue as with 2 channel. An AVR cannot simulate the back 2 channels because they are specified.

My mistake

"Maybe I am thick on that one, but just what do you think currently happens with Source Number of Channels for a 4.0 input file output in a 5.1 output?"  should have been

Maybe I am thick on that one, but just what do you think currently happens  for a 4.0 input file output in a 5.1 output?

[Hendrik]

How does Source Number of Files know the difference between a 4.0 input and a 3.1 input?

Some audio formats actually store a channel layout, and not just a plain number of channels. Audio formats used for multichannel in videos typically always do, but something like DSD does not. However if such information is not present, there is no way to know the difference.

In music, 4.0 is far more common then 3.1, so thats what it interprets it as. If you play that set to 5.1 output, you get a quiet center and a quiet LFE - unless you actually enable MCs bass management, then it would fill the LFE as well.

[RD James]

If you input a 4 Channel File with 3.1 audio in Source Number of Channels, what does it output for 5.1?
If you input a 4 Channel File with 4.0 audio in Source Number of Channels, what does it output for 5.1 output?
How does Source Number of Files know the difference between a 4.0 input and a 3.1 input?
Are you saying it handles both correctly? If so, how does it know what to do with the 2 different 4 channel inputs.

Well my question remains: does such a thing even exist?

You say "I have 3ch tracks which contain 3.0 audio, and 3ch tracks which contain 2.1 audio, and they both play correctly when I select a 5.1 or 7.1 output. 3.0 plays to Left/Right/Center, and 2.1 plays to Left/Right/LFE"
How does MC do that? It must know that one has a Center and one has a LFE?

I assume that it's metadata contained in the file, as the 2.1 tracks are OGGs and the 3.0 files are DTS-HD tracks.
It seems to survive a conversion to FLAC via Media Center, though it does put them inside a 6ch container.

If you put a 5.1 input file into a 7.1 output file, you have the same issue as with 2 channel. An AVR cannot simulate the back 2 channels because they are specified.

Are there AVRs which are capable of doing 5.1 to 7.1 upmixing but cannot handle a 4 or 5 channel input correctly? It feels like you're throwing out a lot of hypotheticals than actual issues.
Media Center has the option to do upmixing from 5.1 to 7.1 itself as well.

[dtc]

Thanks Hendrik. 

So, in fact, the code interprets a 4 channel input file as 4.0 when output to 5.1. So, 3.1 audio in a 4 channel would be interpreted as 4.0 with a 5.1 output.  So, I am mistaken that 4.0 is handled incorrectly. It is 3.1 that is handled incorrectly, because you actually made a decision as to how to handle 4 channel input, as you need to without further mapping information.  So, what happens to a 5.0 and a 6.0 input in a 5 channel or 6 channel input file?

Anyway , most of this is pretty much an academic discussion, given the amount of 3.1/4.0, 5.0 and 6.0 audio in 4,5,6 channel files that are out there.  I am mostly trying to understand what is actually happening here, since the topic comes up occasionally and it is good to know the details.

Thanks.

[RD James]

It is 3.1 that is handled incorrectly

A hypothetical 3.1 track stored in a 4 channel container without any metadata.
 
For what it's worth, I've still not been able to find any 3.1 sources - whether it's in 4ch or other larger containers.
I thought I remembered having seen that on one or two DVDs, but I was either mistaken, or it was on a disc that I've since replaced with a Blu-ray.
 
I've been through about 100 or so DVDs now (the preview function is great for this - though I'd prefer if it started later than 30s into the file) and found two which had 3.0 audio tracks - both inside 6ch containers.

I found another one where the channel mapping is wrong, but as far as I can tell, it's the way that the disc is encoded.
It uses a 6ch container, but there are only four channels of audio: Left/Right/Center and Surround Left.
I thought that it might have been a 3.1 or 4.0 track that wasn't being detected correctly, but listening to the tracks individually, it sounds like it was supposed to have a mono rear channel, that was only encoded to Surround Left for some reason.
 
Fixing discs like that is where it would be really useful to be able to specify channel mapping via tags.

[Hendrik]

I've been through about 100 or so DVDs now (the preview function is great for this - though I'd prefer if it started later than 30s into the file) and found two which had 3.0 audio tracks - both inside 6ch containers.

Thats not actually true, thats just what LAV Audio does by default (and how MC uses it). It avoids so many problems, and processors usually can't upmix such a format further anyway.
I also have some 3.1 DVD rips, its rather unusual but exists. Actually playback failure of such discs is why I added the feature in LAV Audio to wrap stuff into a "common" container in the first place, since back then (long before I used MC or MC used LAV), there was practically no way to play such files properly in things like MPC-HC with HDMI output, since many HDMI devices ignore channel layout info.

[RD James]

Thats not actually true, thats just what LAV Audio does by default (and how MC uses it). It avoids so many problems, and processors usually can't upmix such a format further anyway.
I also have some 3.1 DVD rips, its rather unusual but exists. Actually playback failure of such discs is why I added the feature in LAV Audio to wrap stuff into a "common" container in the first place, since back then (long before I used MC or MC used LAV), there was practically no way to play such files properly in things like MPC-HC with HDMI output, since many HDMI devices ignore channel layout info.

Ah, fair enough then. It still means that Media Center is handling that content correctly.
Does that mean it would be useful to send you an extract from this disc which is outputting L/R/C/SL only?

[Hendrik]

You can probably put it through something like MediaInfo to find out if thats what the file actually contains, because then there isnt much to do.

[RD James]

You can probably put it through something like MediaInfo to find out if thats what the file actually contains, because then there isnt much to do.

Looks like it is actually a 6ch file, just not encoded correctly.
A little frustrating that it's easy to fix via the Parametric EQ, but no way to tag the file so that it happens automatically.
I'd surely forget that the next time I watch it and have to figure out the correct layout again.

[dtc]

Looks like it is actually a 6ch file, just not encoded correctly.
A little frustrating that it's easy to fix via the Parametric EQ, but no way to tag the file so that it happens automatically.
I'd surely forget that the next time I watch it and have to figure out the correct layout again.

From what I read, FFmpeg might be able to rearrange the channels depending on what type of file it is.

[dtc]

Just to try to finish this off, based on Hendrik's comment that audio files seldom contain channel mapping information, I believe a 6 channel 6.0 audio file will always be mapped to a 5.1 output if 5.1 or 7.1 output is specified. That is, one of the channels will be mapped to the LFE channel. Given the rarity of 6.0 audio, that is probably OK. I just wanted to point that out. If I understand correctly, RD seems to say that 6.0 file map fine to 7.1 output, with no LFE channel. Or maybe I misunderstood.  I just do not see how that can be given Hendrik's comment. But hay, if I am wrong just let me know how the magic happens.

As to a 5 channel file, I am not sure how that gets mapped to a 5.1 or 7.1 output. But I presume it is either 4.1 or 5.0, but whichever it is, it is always the same.  Again, not a common format.

[Fitzcaraldo215]

Just to try to finish this off, based on Hendrik's comment that audio files seldom contain channel mapping information, I believe a 6 channel 6.0 audio file will always be mapped to a 5.1 output if 5.1 or 7.1 output is specified. That is, one of the channels will be mapped to the LFE channel. Given the rarity of 6.0 audio, that is probably OK. I just wanted to point that out. If I understand correctly, RD seems to say that 6.0 file map fine to 7.1 output, with no LFE channel. Or maybe I misunderstood.  I just do not see how that can be given Hendrik's comment. But hay, if I am wrong just let me know how the magic happens.

As to a 5 channel file, I am not sure how that gets mapped to a 5.1 or 7.1 output. But I presume it is either 4.1 or 5.0, but whichever it is, it is always the same.  Again, not a common format.

The mapping of 5 channel SACDs using 5.1 output is covered in my test, above in post #1.  It works fine and it also properly handles a mixed 5 and 6 channel SACD playlist. Not included in the test was 5 channel in to 7.1 out, but that works fine, too.  An empty .1 channel appears in the proper output channel, #4, and Surround channels (and expanded Back channels for 7.1) are also mapped to the proper output channels.

Here is a little bit of context and some opinions: 

- SACD is, by far, the single largest source of Mch music, with thousands of available releases since about year 2000, though some much lesser amounts of music exists on BD-A, DVD-A, etc.  Please see the catalog at HRAudio.net and search for SACD Mch vs. BD-A. SACDs are still made and released by numerous boutique labels, though primarily in the classical genre.

- SACD has been difficult to rip to computer libraries due to DRM.  Initially, only specific, increasing scarce models of Sony PS3's with software mods could be used.  Now, specific Oppo, Pioneer, Cambridge, etc. player models can also rip SACDs much more easily.  And, since those players are fairly common and robust, the ripping of SACDs to computers appears to be gathering some momentum among computer audiophiles. A lengthy thread at CA is devoted to this.

- Mch is one of the appealing aspects of SACD for many, and JRiver is popular among library/renderer choices for rips.  I say it is today's best choice, and Mch gurus, like Stereophile's Kal Rubinson, and TAS's Andrew Quint, both agree.  I consider them both friends, so I know.  All of us have very large libraries containing thousands of Mch SACD rips.

- There may be some small, insignificant number of oddball Mch channel configurations on some SACDs.  Chesky, for example, briefly issued Mch SACDs requiring an eccentric speaker layout.  The small, German MDG label also did that, and might still. But, channel mapping is not the big issue there.  The speaker layout configuration must also be physically rearranged to accommodate those weird layouts, which are also totally incompatible with accepted layouts used for Mch video releases.  Hence, their failure or lack of market penetration. Channel mapping alone will not address that, and trying to handle these rare idiosyncrasies in some grand, generalized, complicated mapping scheme is like the tail wagging the dog, IMHO.

- However, the overwhelming majority of labels, including also large majors like RCA and DGG, have consistently by the thousands for Mch SACD used only the ITU 5.0/5.1 channel layouts specified in the Sony/Philips Scarlet Book standard for SACD, either 5.0 in 5 channels or 5.1 in 6 channels.  Both are common.  Both comply with the standard.  Either is used in new releases at the label's option.

- Source Number of Channels does not map 5 SACD channels correctly in numerous systems utilized by JRiver users.  Many of those users are likely completely unaware that there are both 5 and 6 channel SACDs or that a particular Mch SACD they are playing now is one or the other.  They are also likely frequently unaware of how Source Number of Channels does the mapping or that there is even an issue.  A dead or misdirected surround channel is not always easy to spot, particularly if you never heard the recording before. 

- I personally see no use for Source Number of Channels, since it does not handle channel mapping correctly and reliably for 100% of commonly available SACDs, only for some of them, the 6 channel 5.1 ones.  I advise everyone not to use it and use 5.1 instead for SACD.  But, I have encountered a fair number of users who were using it, nontheless.  5.1 always fixed their problem, though possibly it introduced a new problem with intermixed Mch/stereo playlists if 2.0, rather than 2.1 via bass management, output was desired.  The 2.1 output for 2 channel sources, as we know, is a convenient checkbox under the output parameter in DSP Studio.

- 3.0 and 4.0 channel SACDs have already been covered.  They are in 5 channel containers, so there is no mapping problem if using 5.1 or 7.1 output.

- Other Mch formats, like video discs, may also have obscure examples of weird layouts.  I have none in my library.  All Mch examples I own have a .1 channel, which appears to be at least a de facto, widespread standard.  Source Number of Channels causes no mapping problem there, fortunately.  But, 5.1 or 7.1 output also work perfectly in Mch mapping for my video media, again with automatic 2.1 output for 2 channel input.  So, there is no significant advantage to Source Number of Channels I can see.

[dtc]

The mapping of 5 channel SACDs using 5.1 output is covered in my test, above in post #1.  It works fine and it also properly handles a mixed 5 and 6 channel SACD playlist. Not included in the test was 5 channel in to 7.1 out, but that works fine, too.  An empty .1 channel appears in the proper output channel, #4, and Surround channels (and expanded Back channels for 7.1) are also mapped to the proper output channels.

Yes, forgot you did that.

So, if I got it right, my summary would be

4 channel file  --->  5.1 or 7.1 output with empty LFE 

5 channel file  --->  5.1 or 7.1 output with empty LFE 

6 channel file  --->  5.1 or 7.1 output with LFE 

Hope I finally got that right.     

[Fitzcaraldo215]

Yup.  But, it is a bit confusing, and it omits 3 channel. Also, I don't want to guess any more than I already have about sound formats on other media, like BD and DVD. 

So, for SACD Mch, here is my version:

3.0 sound format > 5 channel container > 5.1 output parameter plays 3.0

4.0 sound format > 5 channel container > 5.1 output parameter plays 4.0

5.0 sound format > 5 channel container > 5.1 output parameter plays 5.0

5.1 sound format > 6 channel container > 5.1 output parameter plays 5.1

If no bass management is performed in JRiver, then the .1 Sub channel output is empty, except for 5.1, where it is the .1 LFE input channel.

If 7.1 is the output parameter, expansion from Surround to Back channels is added, except for (I think?) 3.0.

Also, with JR bass management on and the "For stereo sources, only mix to 2.1" box checked, I get:

2.0 sound format > 2 channel container > 5.1 output parameter plays 2.1 output

I have not encountered any other possibilities on SACD.