Leozack
26th May 2002, 02:14
Recently I've re-encoded an anime movie I previous encoded (in Divx5 using Gknot) using Divx311 with more manual method (vfapi/nandub etc). However, I've had some rather weird turns of events =/
Firstly - whenever any sound ripping program wants to work (usually they all use LAME) the DOS window ends up being spammed with this in the DOS window
<> RevSizeInternal buffer inconsistency. flushbits
<> RevSizeError: MAX_HEADER_BUF too small in bitstream.c
repeatedly for each frame it tries until it's finished. This doesn't happen straight away, usually only halfway through encoding. If I try to use Vob2Audio or GraphEdit, both fail =/
As if that wasn't annoying enough (I can get round it by only making a WAV file from Gknot, and then using an audio mp3 maker (audio catalyst) to make a cbr 128kbs MP3 of it) The 2 final results (divx5 and divx3) in avi format work well, but when opened in VirtualDub give the following messages. I don't know how serious the error is but they play fine. Anyway, anyone who's bothing to even read this is welcome to tell me anything they know of if they've seen or heard of such problems before, especially a way out of it! =D
Here's the Vdub errors:
Divx 5.0.1
Virtualdub has detected an improper VBR audio encoding in the source AVI file and will rewrite the audio header with standard CBR values during processing for better compatability. This may introduce up to 7746 ms of skew from the video stream. If this is unacceptable, decompress the *entire* audio stream to an uncompressed WAV file and recompress with a constant bitrate encoder. (bitrate: 120.9 + 13.1 kbs)
Divx 3.11
Virtualdub has detected an improper VBR audio encoding in the source AVI file and will rewrite the audio header with standard CBR values during processing for better compatability. This may introduce up to 0 ms of skew from the video stream. If this is unacceptable, decompress the *entire* audio stream to an uncompressed WAV file and recompress with a constant bitrate encoder. (bitrate: 128.0 + 0.0 kbs)
Thoughts anyone? =/
Firstly - whenever any sound ripping program wants to work (usually they all use LAME) the DOS window ends up being spammed with this in the DOS window
<> RevSizeInternal buffer inconsistency. flushbits
<> RevSizeError: MAX_HEADER_BUF too small in bitstream.c
repeatedly for each frame it tries until it's finished. This doesn't happen straight away, usually only halfway through encoding. If I try to use Vob2Audio or GraphEdit, both fail =/
As if that wasn't annoying enough (I can get round it by only making a WAV file from Gknot, and then using an audio mp3 maker (audio catalyst) to make a cbr 128kbs MP3 of it) The 2 final results (divx5 and divx3) in avi format work well, but when opened in VirtualDub give the following messages. I don't know how serious the error is but they play fine. Anyway, anyone who's bothing to even read this is welcome to tell me anything they know of if they've seen or heard of such problems before, especially a way out of it! =D
Here's the Vdub errors:
Divx 5.0.1
Virtualdub has detected an improper VBR audio encoding in the source AVI file and will rewrite the audio header with standard CBR values during processing for better compatability. This may introduce up to 7746 ms of skew from the video stream. If this is unacceptable, decompress the *entire* audio stream to an uncompressed WAV file and recompress with a constant bitrate encoder. (bitrate: 120.9 + 13.1 kbs)
Divx 3.11
Virtualdub has detected an improper VBR audio encoding in the source AVI file and will rewrite the audio header with standard CBR values during processing for better compatability. This may introduce up to 0 ms of skew from the video stream. If this is unacceptable, decompress the *entire* audio stream to an uncompressed WAV file and recompress with a constant bitrate encoder. (bitrate: 128.0 + 0.0 kbs)
Thoughts anyone? =/