MediaInfo - Audio Channel(s)_Original: 6 channels

[pizzaboyUK]

Is this as it sounds? Usually this comes after "Channel(s): 2"... Was this originally a 6 Channel (ie. 5.1 AC3 file) thats been converted to stereo?

I ask because I've come across several files which have an Audio#1 & Audio#2 (sometimes in the same format) - seems strange that a video file would have two audio files both in stereo format?

I like to have videos with surround sound even though I currently (emphasis "currently") don't have a system to test them....

[Cornucopia]

There are a number of (usually professional) formats that contain multiple streams of stereo or mono channels. Not that unusual.

Plus, when most DV apps (both Mac & Win) transfer DV from tape to HDD, they do it in "Type 2" format. This reads the pre-muxed/interleaved audio and creates a duplicate, non-interleaved standard audio stream. Very common.

Neither of these are necessarily referring to surround sound (possible, but not really likely).

Scott

[pizzaboyUK]

Any way to test if the video is surround or not, if I don't have a surround system available? Some kind of graphic equalizer to visually show something is passed through all channels would obviously be preferable.

I just find it weird as to why MediaInfo would specifically point out the original channels (I gather this was information directly taken from the source) if there weren't any changes made...


Forgot to mention: I received the file from someone who specifically said it did have 6 channels which makes it a little more suspicious...

[Cornucopia]

Ok, that is a little suspicious.

My guess is that, since MediaInfo can get its info from (usually) one of 2 places (container header, elementary stream header), maybe there is a conflict, and that is MediaInfo's way of explaining it. Rarely do containers provide metadata in the form of "original...". And, much as I would love to see a way of maintaining end-to-end mediafile provenance, that isn't a current reality.

This is one area that I want to see MediaInfo improved upon: explaining exactly WHERE it pulled its info from.

Scott

[pizzaboyUK]

Yeah, I hope its MediaInfo getting the info wrong, meanwhile I need a way of checking so I don't waste time editing and encoding the file then looking quite silly at the end of it all...

I did assume that MediaInfo was smart enough to perform a check on the stream rather than any coded information embedded in the file which makes it all the more confusing.

[hello_hello]

This is how the author of QAAC explains it:

http://www.hydrogenaud.io/forums/index.php?showtopic=85135&st=625&p=867076&#entry867076
mp4a.channelcount is intentionally set to either 1 or 2, since in the former spec (ISO 14496-12) only 1 or 2 was allowed. However, it seems that no such restriction present in the new spec (4th ed @2012-7-15). Therefore, maybe I should fix qaac to write actual number of channels.

On the other hand, I can say for sure that nothing in AudioSampleEntry (mp4a) matters and cannot be taken seriously.
For example, samplesize field (typically it is 16) is non-sense for AAC.
samplerate field is 16.16 fixed-point, so not enough to represent high samplerate such as 96kHz.
I don't understand why MediaInfo looks at it at all.

I tested the popular AAC encoders, and for the record, it appears NeroAAC is the only encoder which doesn't write the obsolete data, as when you view an MP4/M4A written by Nero with MediaInfo, it'll simply show the correct channel count. MyMP4BoxGUI writes it when muxing.
There's ways to look at the audio to confirm it's multi-channel-ness, such as playing it with foobar2000 and looking at the output meters. The channel count displayed will change according to the audio being played.



You could import it into Audacity to check the channel count but that's pretty slow.

Or you can open the MP4/M4A with MKVMergeGUI and resave it as an MKA/MKV. Maybe the obsolete channel count data gets dumped by MKVMerge during the re-muxing process or it's ignored by MediaInfo when the container is MKA/MKV, but MediaInfo will simply report it as being 6 channel when the AAC audio is in an MKA/MKV container.

Or you could extract the audio with MyMP4BoxGUI and get MediaInfo to look at the extracted stream.

Bottom line: It's normal, the audio is 6 channel, and don't take what MediaInfo says as gospel.

I like to have videos with surround sound even though I currently (emphasis "currently") don't have a system to test them....

I keep the audio as multichannel and I only have a stereo system. Plus I think surround sound sucks.... but you never know. One day I might change my mind.....

Edit 1: I guess I assumed the audio in question is AAC. I don't know if the same applies to AC3 or other formats in an MP4/M4A. I don't even know what types of audio you can put in an MP4/M4A container these days.

Edit 2: As a quick test I put some multichannel AC3 audio in an MP4 with MyMP4BoxGUI and MediaInfo only reported 6 channels. But when it's AAC it shows "channels 2" and "original channels 6".

[El Heggunte]

This is how the author of QAAC explains it:

http://www.hydrogenaud.io/forums/index.php?showtopic=85135&st=625&p=867076&#entry867076
mp4a.channelcount is intentionally set to either 1 or 2, since in the former spec (ISO 14496-12) only 1 or 2 was allowed. However, it seems that no such restriction present in the new spec (4th ed @2012-7-15). Therefore, maybe I should fix qaac to write actual number of channels.

On the other hand, I can say for sure that nothing in AudioSampleEntry (mp4a) matters and cannot be taken seriously.
For example, samplesize field (typically it is 16) is non-sense for AAC.
samplerate field is 16.16 fixed-point, so not enough to represent high samplerate such as 96kHz.
I don't understand why MediaInfo looks at it at all.

Thanks for the comprehensive info

Now, at last, I know one VERY-good reason why AAC was not included in the Blu-Ray specs

So there are only 4 audio formats which surely do not suck at multichannel handling:

* AC3

* DTS

* DTS-HD

* MLP/TrueHD

[hello_hello]

I've been encoding multi-channel audio as AAC for years, and I've never had a problem with it. I'd never even noticed the issue in question because the first thing I do after the audio is encoded is mux it into an MKV along with the video, and MediaInfo then reports the channel count correctly. Or if I had noticed, I'd just not paid any attention to it. It'd be like believing what MediaInfo reports for aspect ratios.
The subject came up at doom9 a while ago in a thread I was posting in, otherwise I'd probably still be oblivious to the reason myself.

The way I read the explanation here, it seems that MediaInfo knows to ignore the obsolete channel count for other audio formats but for some reason it doesn't for AAC. Whether that's correct or not...... but I also assumed the "mp4a.channelcount" problem was a container level problem (ie MP4) and nothing to do with the audio stream (ie AAC) as such. Whether that's correct or not.....

However..... if you take one of the offending MP4/M4A/AAC files and extract the AAC audio with MyMP4BoxGUI and check the raw AAC with MediaInfo it'll simply report 6 channels (or whatever the correct channel count may be). Therefore, I don't think it's AAC's fault.

[hello_hello]

My guess is that, since MediaInfo can get its info from (usually) one of 2 places (container header, elementary stream header), maybe there is a conflict, and that is MediaInfo's way of explaining it.

I think it's a good guess. The same applies if you remux video while changing the display aspect ratio. MediaInfo will report "original display aspect ratio" and "display aspect ratio". Or it'll report "original frame rate" and "frame rate" etc. It's probably safe to assume "original" means the data is coming from the video or audio stream and the value reported without the "original" designation is the container level data. If they're both the same, MediaInfo doesn't report the same value twice.

[Cornucopia]

It would be so much more helpful if it laid out, via tooltip or "expert detail" pane, where those all came from and any decisions it had to arrive at. I'd bet that 99% of MI's "uncertainty" or "inaccuracy" could be cleared up by just doing that.

Never thought about a v1 vs. v2 spec header flag conflict before (such as you expound re: AAC). I'd guess the MKV "3D" flags would have similar deprecated alternatives.

Of course, part of the difficulty might be in how the file was muxed, and that's not the fault of MI. Not like it has ever attempted to be a "compliance checker" type of app...

I await pizzaboyUK's actual MI text readout post or, even better, a clip upload.

Scott

[pizzaboyUK]

Thanks for such informative answers guys.

I await pizzaboyUK's actual MI text readout post or, even better, a clip upload.

Scott, its not really an isolated case, and as I don't really know for certain the very origin of the source file or if any editing has been done - MI readout would probably be a bit pointless (it reads as I stated and no further details are really given).

Cheers.

[hello_hello]

pizzaboyUK,
Can you at least confirm whether the audio in question was AAC in an MP4/M4A container???

[pizzaboyUK]

Yes, it is.

MP4/AVC. AAC audio. Though I've had several similar files - so can't really verify whether they all were...

[El Heggunte]

Apologies for not having been clear enough...

The *strong point* of AC3, DTS and MLP is,
both the channel count and the channel layout are WELL-DEFINED (id est, explicitly-flagged) in the frame headers of the elementary stream.

Sadly one cannot say the same about Vorbis, AAC, FLAC, WMA Pro, WMA Lossless (or even ALAC - ).

Yes, one should not assume "multichannel audio == 5.1, 6.1 and 7.1 only",
nor "let the decoder decide" what to do when the audio stream has just 3, 4 or 5 channels...

[pizzaboyUK]

El Heggunte, I've always had a preference for AC3, if not only from a technical perspective - I feel its just simply easier to handle when encoding files.

In fact I re-encode most of my files (ok... actually all of them ) to AC3 - hope I'm not losing anything in the process

[El Heggunte]

As long as you use the bitrate required for "perceptual transparency", that is to say, 128kbps per channel,

there should be nothing to worry about

[El Heggunte]

I excluded WavPack from post #14...

well, even though it seems to be a "sane format" (according to Kostya),
there is only one container which supports it (Matroska), but the support is broken and won't be fixed "anytime soon"

https://trac.bunkus.org/ticket/859