#413 AAC (LC) reported as 2 channel rather than 6 channel

More_attribute
open-accepted
5
2014-01-22
2013-07-07
Kevin Marchant
No

As of 0.7.64 the AAC soundtrack in my MP4 files are now being reported as

English, 315Kbps, 48.0 KHz, 2 channel, AAC (LC)

Reverting to 0.7.63 reports the track correctly as

English, 315Kbps, 48.0 KHz, 6 channel, AAC (LC)

Discussion

1 2 > >> (Page 1 of 2)
  • There were some changes in this part of the code, with a difference between container information and raw stream information.
    Do you see 2 values ("2" and "6"_ in the full views (Text, HTML, Tree...)?

    If not, I need a sample file (it can be short or cut)

     
  • Kevin Marchant
    Kevin Marchant
    2013-07-08

    Here's the text view - yes, Original Channel count = 6 and Channel(s) = 2 in version 64 but Channels(s)=6 in version 63

    In 0.7.64
    Channel(s) : 2 channels
    Original Channel count : 6 channels

    In 0.7.63
    Channel(s) : 6 channels

     
    Last edit: Jerome Martinez 2013-07-08
  • So this is the intended behavior: I display now the content of the container. I have some 5.1 files having "6" in the container channel count, some others having "2" (like yours) and it is not normal.

    I need to find a method in order to display some information when container and stream information are different.

     
  • Ticket moved from /p/mediainfo/bugs/773/

     
    • labels: Audio, AAC, LC --> Audio, AAC, LC
    • status: open --> open-accepted
    • assigned_to: Jerome Martinez
    • Group: Incorrect_result --> More_attribute
     
  • Feature needed: better display of incoherencies between container and raw stream.

     
  • raekwonchef
    raekwonchef
    2013-12-15

    Any update on this? It seems when I convert WTV files using Bigasoft WTV Converter, that I am seeing the same exact thing in 0.7.64 (2 channels - 6 original).

     
  • No update.
    The current core implementation is the correct one (displaying the problem between container and raw stream), and thinking about how to better display such errors is a long term feature, and not currently a priority (sponsored feature requests have priority).

    In the meanwhile, don't hesitate to report the bug to your encoder provider ;-).

     
    • Allan Strydom
      Allan Strydom
      2014-01-22

      Hi

      I've written an app that leverages MediaInfo heavily and I've just run into this same issue.

      I have a few questions on this:

      1

      Are you saying that you are using the channel count from the container as the primary value and as a preference over the channel count reported in the stream itself ?

      That's what you seem to be saying, but I don't understand why you would do that in the context of where MediaInfo is showing that information. MediaInfo shows that information in the Audio Stream section, so I would think it would always make sense to use the channel count reported by the stream as the primary value, and if there is a difference, give the count from the container as the extra value ?

      It seems to me that the channel count from the stream itself will always be correct and it's only the container count that might be wrong because of a bad mux, so it follows that it would be safer to always use the count from the stream itself as the primary ?

      2

      My other question is, if a file has multiple audio streams, then how do you extract multiple channel counts from the container ? This question is more for me to understand at a technical level how this works. Do the containers store the channel count for every audio stream embedded in them independently of the streams themselves ?

      Thanks for an excellent product.

      Allan

       
      Last edit: Allan Strydom 2014-01-22
  • Are you saying that you are using the channel count from the container as the primary value and as a preference over the channel count reported in the stream itself ?

    Yes and no:
    - in the default GUI view, yes it has preference, I display container information (and it should be changed to display both because raw stream information is important for this information)
    - in the text view, the DLL API and so on, I provide both values, no preference. In your tool, you check if the value from the stream, if it is empty you take the one from the container (empty means same value as container): check if "Channel(s)_Original" exists", if yes use this value else use "Channel(s)" value.

    MediaInfo shows that information in the Audio Stream section, so I would think it would always make sense to use the channel count reported by the stream as the primary value, and if there is a difference, give the count from the container as the extra value ?

    MediaInfo has no information about what the decoder will do: will your player prioritize the data from container or stream? Usually, it depends of which data (e.g. channels, ok, stream data has often priority but sometimes the output in truncated to 2, and for frame rate container data has often priority...)
    So MediaInfo provides both values, do what you want with them, you can decide of the priority.
    It is in Audio section, but it is about the output from this file, container information included. Audio section is not about the raw stream, it is about the audio program being played (e.g. if the raw stream says your file has channel config Left then Right, but container config has a command "I know it is Left then Right, but the raw stream is badly encoded so put Right then Left", the container information has priority)

    For audio channel count, it is easy, 99% of the time the raw stream info has priority, but I have other information without so obvious behavior e.g. for audio sample rate in MOV, 50% of players use the container sample rate, 50% of players use the raw stream sample rate, which one should I prioritize? I decided to display first container information and optionally raw stream information if not same as container information.

    , so it follows that it would be safer to always use the count from the stream itself as the primary ?

    MediaInfo provides both because some people want the value of the container too, then you do what you want. Again, it is the way ALL fields are designed, I can not change easily in the MediaInfo workflow one field behavior because we know it is "safe" to use the raw stream value. Other users use automation to check container/raw stream incoherency, so they need a stable method to display container and raw stream information whatever is the safety of each field.
    It does not prevent you to get data the way you want (you do the job of knowing which MediaInfo piece of data is "safe" or not from your point of view)

    My other question is, if a file has multiple audio streams, then how do you extract multiple channel counts from the container ?

    Container has information per raw stream (1 container entry per raw stream).

    Do the containers store the channel count for every audio stream embedded in them independently of the streams themselves ?

    Yes

    Thanks for an excellent product.

    Thanks :)

     
1 2 > >> (Page 1 of 2)