Precision of bitrates (and lengths) for files

[Caster]

OK i didn't want to do this but the compression mod insisted

Today i got message about this creq (which turned out to be certain's mod modedit), which resulted in some discussion on IRC...

For the file length, mine was from MPC, while MatroskaDiag says 00:45:27.717 so the edited 45:28 could be more correct, but why would anyone care to correct this? And then fix just the 0 video bitrate (I admit i'm lazy to check it for mkv's) and leave audio 0 alone?

So I ran some bitrate test in matroskaprop (crashed as always) and then virtual dub which said:
Video: 1152, Audio 1: 113, Audio 2: 111.6.
So I suppose this is what nwa used.

Mycroft used The Matroska Infomation CDL v1.81 in the core media player. (whatever)
Video: 1077, Audio 1: 104.52, Audio 2: 102.93.

So what to believe? What to choose? How to fill audio if there are more streams? (Personally I would just fill what's for the Japanese one.)

[Rar]

My personal hope is that an open spec AOM 0.6 will become the standard for judging all of this stuff. The current tools can be wildly inaccurate, largely due to not properly taking container overhead into account, or generaly just being outdated. As for file timings, I've rounded up at .5 in the past. Overall, don't panic too much, and hope all these little discrepancies get auto creqed by a future AOM, where petri has doccu stating what he rounds and how.

Rar

[Caster]

Thanks for the vast interest.

Anyway I demuxed the culprit file and measured the avi and ogg separately.

AOM says the video is 1 151,78 kb/s, and winamp about the ogg: Average bitrate : 114 kbps.
That means the virtualdub is pretty close and core media player fails. So if anyone bothers with adding bitrates, vdubmod seems to be the tool to use for now.

Still I don't feel like running updating all my mkv entries, or even creqing others... Now when rar said this about AOM 0.6...

[nwa]

Caster, I normally don't go editing lengths which differ only by 1 second unless there are other stuff to change.
I used VDubMod to get the video bitrate, but vdubmod often fails when determaining the correct audio bitrate so it gave me like 454573.5 for audio bitrate.
Usually I just demux the audio from the mkv and get its bitrate using winamp and foobar2000, the problem is that they both report different bitrates... so far I've gone mostly with foobar's bitrates which seem to be lower, but not all the time, but I was in a hurry back then to do so.

And yes, in dual audio, one shold add the Japanese audio stream's bitrate.
And yes, vdub(mod) is the best tool for getting bitrates atm.

[Cyrano423]

This is something I recently found myself interested in due to a previous creq. AVDump (which I started using per suggested by Der Idiot) consistently reports the mp3 audio as CBR ... but upon watching it the bitrate varied, thus indicating it as VBR. For awhile I wondered if the mp3 file was CBR at first but is handled differently when combined with video.

Though due to this dicussion and the demuxed files ... I guess it's safe to assume that the CBR classification of AVDump is generally wrong, and VBR should be indicated when submitting a file. If the bitrate fluctuates. Is this safe to assume? Also, the entries with 128 CBR, that should actually be VBR ... the bitrate is grossly incorrect, because there's no such thing as a standard 128 VBR, the closest they can come is a 128 ABR, which merely stays within the 128 range, but isn't actually averaged @ 128.

Though I imagine many people don't know the difference between CBR, VBR, and ABR unless they are avid users of Lame.

*shrugs*

[epoximator]

when you find files like that just report them (fids) to me and i will, hopefully, fix avdump. (join #anidb, or just pm me in this forum)

[Cyrano423]

when you find files like that just report them (fids) to me and i will, hopefully, fix avdump. (join #anidb, or just pm me in this forum)

cool, will do.

[nwa]

Did you try demuxing the audio and looking at the bitrate in foobar2000 or did you topen the file in vdub, if those report it being cbr as well, then it probably still is cbr.

[Cyrano423]

Did you try demuxing the audio and looking at the bitrate in foobar2000 or did you topen the file in vdub, if those report it being cbr as well, then it probably still is cbr.

I didn't demux it at all. When I was creqing one of the files, I noticed that the audio information said 192 CBR ... but as I was looking at it in AOM (which is erroneous at the moment) I saw that the audio bitrate wasn't a CBR bitrate. So that led to random curiosity. I then opened the file in various players ... VLC, MPlayer, TCPMP, Windows Media Player, Quicktime ... and all of them showed that the bitrate for audio varied as it was playing. Which to me was common sense ... if the bitrate isn't constant then it can't be CBR.

However, since avdump was basically the rule of thumb suggested by Der Idiot, I decided to drop my curiosity thinking "doesn't matter, if avdump is reporting this then that's what should be in the file info." I casted away my perception with CBR vs ABR & VBR ... thinking, "there just must be something I'm not getting about combined audio with video, maybe the audio file was CBR but with syncing with video, the rate is adjusted so the timing matches ... or the bitrate varies purely because the entire file's bitrate varies, and the CBR mp3 is still CBR, but it's the video combination which is VBR"

I dunno ... I guess I was just trying to rationalize going with avdump's reportings, lol. I'm not really a person who's into video which is why I was just guessing @ rationalizations, but MP3 audio is definitely my thing or has been for the past 5 years that I've been using Lame (since I rip my CDs myself with EAC, and had to learn the various modes and changes they made to it over the years).

Though I see now it might've been an issue with avdump. I'll make sure to demux it next time ... and make note of the file id, so that bug or error can be fixed.