MediaInfo shows wrong Samples Count/Duration for M4A Files

2013-01-17
2013-01-17
  • robertcollier4
    robertcollier4
    2013-01-17

    For the same file, test.m4a of the type: "AAC-LC Encoder, TVBR q127, Quality 96", MediaInfo gives the following wrong information about "Samples Count" in "Debug > Advanced Mode". The information differs from the correct information given by "mp4box -diso"

    MediaInfo Gives Wrong Values:
    Samples count : 127772688 (wrong, 16 samples too big)

    "MP4Box.exe -diso" Gives Correct Sample Count:
    TrackHeaderBox Duration="127772672"

    This was discovered on hydrogenaudio here and how to get the correct output via mp4box output was explained here.

    It would be nice if MediaInfo could correctly report Samples Count for m4a AAC files.

    Also it would be nice if MediaInfo would display the "Encoder Delay", "Padding", and "Original Sample Count" decimal values reported in hex form in iTunSMPB tag in a M4A file. Thanks.

     
    Last edit: robertcollier4 2013-01-17
  • Samples count : 127772688 (this is the wrong value for this file, should be 127772672)

    There are sometimes non precise information in MediaInfo, due to rounding issues (and it should not, when it is possible, but to be honest, accuracy of this field was not my priority).
    Please open a bug ticket with the corresponding .mp4 file (I can provide a private FTP server access if you need one)

    Duration : 2661931 (this is the wrong value for this file, should be 124778)

    Very weird. Please open another ticket (I don't think that it is the same bug).

    Also it would be nice if MediaInfo would display the "Encoder Delay", "Padding", and "Original Sample Count" decimal values reported in hex form in iTunSMPB tag in a M4A file.

    I quickly searched for specifications, but I find no one.
    What is the exact meaning of each byte (or 4-byte items)?
    Please open a feature request ticket with more details (an example of the result you expect and a sample file if iTunSMPB is not in the same file).

     
  • robertcollier4
    robertcollier4
    2013-01-17

    Thanks, I have opened Bug 730.

    And actually it seems that Duration is being reported fine. Duration anyways is supposed to be calculated from Samples Count so if Samples Count is correct then Duration will be correct.

    Update: I think the problem is coming from rounding error that is introduced from calculating "Samples Count" = Duration * Sample Rate.

    However, this is the wrong way of doing it, since Duration already has rounding in it.

    You should first calculate "Samples Count". Then calculate Duration in milliseconds from:
    1000 * Samples Count / Sample Rate

     
    Last edit: robertcollier4 2013-01-17