Wmcmd.vbs: Final bit rate always lower than expected

[bluesk1d]

For some reason the average bit rate of the CBR encodes I do are always less than what I define... Sometimes WAY lower. The example below is The Italian Job. I just got done with Sky Captain and the final result was about half of what it should have been! I use a wmv bit rate calculator to try to create files that will fill up a DVD9 disc for max quality. This is getting really annoying!

Does anyone know what component in my process may be at fault?

Graph:
Haali media splitter (decrypted EVO) -> wmv DMO decoder

AVS:
DirectShowSource("C:\dvd-temp\evo1.grf",fps=23.976,framecount=76896,seekzero=false,seek=true,audio=false)+DirectShowSource("C:\dvd-temp\evo2.grf",fps=23.976,framecount=76488,seekzero=false,seek=true,audio=false)
spline36resize(1280,720)
converttoyv12()
Removegrain(mode=2)
Asharp(2,3)

It should also be noted that cscript almost always crashes at the beginning of an encode. I usually move the error message out of the way off the screen and ignore it. The encodes finish and it doesnt seem to be much an issue. The crash claims the culprit is qasf.dll. This is a fresh XP install with only minimal components installed (wmp11, ffdshow, haali, etc) so there isnt a bunch of extraneous junk loaded.

Example output:
cscript.exe "C:\Program Files\Windows Media Components\Encoder\WMCmd.vbs" -input "C:\input.avs" -output "C:\output.wmv" -v_codec WVC1 -videoonly -v_mode 0 -v_preset better -v_bitrate 9378984 -v_keydist 30 -v_buffer 60000 -v_quality 100

Source duration retrieved: 6632.094 seconds.

Encoded: 6632s (100%) Elapsed: 08:42:50 Left: 00:00:00 [0.21x]

======== Encoding Completed ========

Video :
Codec: Windows Media Video 9 Advanced Profile
Expected bit rate: 9378984 bps
Average bit rate: 7644828 bps
Expected fps: 23.976
Dropped frame count: 0
Total coded frames: 159011
Average sample rate: 23.952
Dropped bytes: 0 bytes
Total bytes: 6337616750 bytes

Overall:
Encoding time: 31383 seconds
Average bit rate: 7644828 bps
File size: 6366309218 bytes
File duration: 6632.086 seconds

[zambelli]

It should also be noted that cscript almost always crashes at the beginning of an encode. I usually move the error message out of the way off the screen and ignore it. The encodes finish and it doesnt seem to be much an issue. The crash claims the culprit is qasf.dll. This is a fresh XP install with only minimal components installed (wmp11, ffdshow, haali, etc) so there isnt a bunch of extraneous junk loaded.
That's coming from the internal decoding graph. QASF is the component responsible for wrapping WMV Decoder DMO as a DirectShow filter. I'm guessing something is not right with the way the VC-1 stream is being passed out of the EVO to the WMV decoder.

Expected bit rate: 9378984 bps
Average bit rate: 7644828 bps
It might be just a coincidence, but the ratio of these two numbers is 4:5 - the same as the ratio of 24 fps to 30 fps. I wonder if it's somehow possible that the EVO parser is reporting 23.976 fps as the framerate, but in reality serving 29.97 fps or 59.94 with repeated frames. You should try saving the .avs to an uncompressed AVI via VirtualDub and checking it for duplicate frames.

Also, I notice that the source is 76896 + 76488 = 153384 frames (6397 seconds) long, but the source is identified as being 4 minutes shorter - 159011 frames or 6632 seconds. I wouldn't be surprised if that's indicative of a bigger problem.

[bluesk1d]

Good obs on the slight duration difference. I hadnt noticed. I am not all that familiar with how everything works behinds the scenes so you'll have to bear with me but even if the EVO was being processed stragely by something in the graph, wouldnt the AVS script limit it to 23.976 before it even got to the encoder portion of the process?

[zambelli]

Good obs on the slight duration difference. I hadnt noticed. I am not all that familiar with how everything works behinds the scenes so you'll have to bear with me but even if the EVO was being processed stragely by something in the graph, wouldnt the AVS script limit it to 23.976 before it even got to the encoder portion of the process?
There's a lot that can go wrong behind the scenes. Just because a filter requests 23.976 fps doesn't mean it's going to get true 23.976 fps. For example, what if the EVO parser _claims_ it's outputting 23.976 fps but is in reality putting time stamps 33 msec apart (29.97 fps)?

I'm not familiar with the HD-DVD ripping tools and I've never tried the whole EVOB conversion process, but since the whole thing is still in its infancy, I wouldn't be surprised if it's not perfect. I would definitely recommend that you try outputting to an AVI format and then inspect the output frame by frame to ensure no repeated frames are occurring.