Zend certified PHP/Magento developer

Why the discrepancies between ffprobe and mediainfo.DLL?

I wrote some logic to compare information from ffprobe vs. MediaInfo.DLL. Observations and questions:

A) Most of the differences were small variations in the lesser significant digits of various numeric values (bit rate, duration, frames per second), but I had no way to determine which one was actually more accurate. Any thoughts on whether the slight discrepancies between ffprobe’s output and MediaInfo.DLL’s output are significant, or how to evaluate which one is more accurate?

B) For one WMV file, MediaInfo.DLL reports a Bits Per Sample of 16. My understanding is that BPS and bit depth are just two different names for the same thing, but ffProbe is unable to determine a BitDepth. I think that probably ffProbe is correct because the Audio codec is wmav2, which apparently uses a very low quality lossy compression that probably makes bit depth meaningless. So I’m wondering if maybe MediaInfo.DLL is just seeing the WMA format and blindly assuming 16. Another (AMR) file has a similar thing, where MediaInfo.DLL reports a BitDepth of 14. (In the case of this file, ffProbe reports a bit rate of 9200, compared to 0, as reported by MediInfo.DLL). Is there a reliable way to determine whether the BPS from MediaInfo.DLL is actually meaningful and correct?

C) For one WEBM file, ffProbe shows a video bit rate of 0 as well as an audio bit rate of 0. This video bit rate seems to coincide with the Video Data rate of 0kbs reported for the file on the Details tab of the Properties window for the file. However, MediaInfo.DLL reports a video bit rate of 439316 bps and an audio bit rate of 64000 bps. In this case, the audio bit rate matches the one reported in the File Properties. The only bitrate ffProbe’s reports is 533294 (without specifying whether this is supposed to be audio, video, combined, or something else). In the “Even More Information” view from MediaInfo.DLL, this is reported as the overall bit rate. It is sort of in the ballpark of the combined audio and video bitrates, so it may be that some or all of these rates are “target” bit rates (since webm is lossy). I divided the video stream size by the duration in seconds and got 54,914.439… Likewise, for the audio stream, it comes out to an even 8000. So MediaInfo is apparently not just doing the math to calculate an average audio and video bit rate. Any idea what might be going on or whose interpretation of reality is correct?

You can find my sample media files here