DVD2SVCD or CCE or TMPGEnc 'Possible Issues'

[mkanar]

This is simply some documentation of potential issues with DVD2SVCD (v1.0.7 build 4) or CCE (v2.50) or TMPGEnc (using v2.53) or other.

The machine used for encoding is as follows:
Athlon 1700 XP running @ spec of 1.47GHz
256MB DDR PC2700 CAS2 running @ PC2400 CAS2
WindowsXP

Frequently, DVD2SVCD will crash with an access violation during the subtitle selection after hitting the 'show next' button several times.

Last night, I attempted to encode a 113 minute DVD w/audio1@224kbps and audio2@80kbps. I setup the bitrate for 2 800MB CDs which yields a bitrate of 1613 on the 'Bitrate' tab. Max=2432, Min=100, Min Avg=1500, Max Avg=2312. If the max bitrate is set to high (ex. 2500) and I click on the 'conversion' tab, I get a dialog box as follows:

"Error"

The total bitrate (audio+video = 2804 kbps) is bigger (er, larger) than the max. bitrate specified in the SVCD standard (2756 kbps). Some players might not be able to play this SVCD.

Do you want to continue?

[YES] [NO]

However, it doesn't seem to make any difference if I select [YES] or [NO]. Should it, or am I missing something?

Anyhow, I selected CCE 5-pass for encoding. For some reason, I have never had any CCE problems on this particular machine/configuration until this encode. At 17%, I got an 'invalid checksum error.' In this particular encode, the spread between average bitrate and max bitrate was rather large, (835 kbps):

Executing Cinema Craft Encoder.
...
Min. bitrate: 100
Max. bitrate: 2432
Avg. Bitrate: 1597

I guess that I've missed this small bit of information in the past, but if I simply hit 'OK' when the checksum error appears, then the CCE encoding continues (perhaps until the same place in the next pass). It is obviously inconvienent to have to hit the 'ok' button several times during the encoding process, each seperated by a few hours of encoding time. However, if I do hit the 'ok' button and refuse to cancel the encoding process, will the resulting video stream be valid?

Regardless, I decided to cancel and crash recover at the 'video encoding' stage with TMPGEnc. Some of the TMPGEnc data is as follows (take notice of the calculated CQ values):

Pointers: 3470
- Encoding Test Clip J:\Out\AviSynth_Script_file_CQ_TEST.avs
...
Seconds: 6824.44
CalcMPEGStream: 1363042883.60
Frames: 163383
CDSize: 800.00
Cut point 792.00
Calculated Quality Value: 80.00

- Encoding Test Clip J:\Out\AviSynth_Script_file_CQ_TEST.avs
...
Test Clip: Got MB per Frame: 4846.4975
Test Clip: Want MB per Frame: 8342.62367320958
Test Clip: CQ per Frame: 0.0165067659686196
Test Clip: New CQ value: 137.709736537936
Test Clip3: Calculated CQ value: 108.854868268968
Calculated Quality Value: 108.85 Isn't 108.85 larger than the max valid value of 100?

- Encoding Test Clip J:\Out\AviSynth_Script_file_CQ_TEST.avs
...
Test Clip: Got MB per Frame: 10702.176
Test Clip: Want MB per Frame: 8342.62367320958
Test Clip: CQ per Frame: 0.0101712836967891
Test Clip: New CQ value: 84.8551921557638
Test Clip2: Calculated CQ value: 96.8550302123659
Calculated Quality Value: 96.86

- Encoding Test Clip J:\Out\AviSynth_Script_file_CQ_TEST.avs
...
Test Clip: Got MB per Frame: 10387.3955
Test Clip: Want MB per Frame: 8342.62367320958
Test Clip: CQ per Frame: 0.00932428443803511
Test Clip: New CQ value: 77.7889960884913
Test Clip1: Calculated CQ value: 87.3220131504286
Calculated Quality Value: 87.32

- Encoding J:\Out\AviSynth_Script_file.avs
...
Test Clip: Got MB per Frame: 7342.3585
Test Clip: Want MB per Frame: 8342.62367320958
Test Clip: CQ per Frame: 0.0118929105886656
Test Clip: New CQ value: 99.2180774203662
Test Clip0: Calculated CQ value: 93.2700452853974
Using Quality Value: 92.48


Anyhow, the resulting .mpv was 1,462,118,463 bytes; bbMPEG_00=832,805,400 bytes, bbMPEG_01=933,727,424 bytes; CD_Image_1.bin=844,821,936 bytes, CD_Images_2.bin=946,388,352 bytes.

I'm uncertain if the TMPGEnc calculations were wrong due to a statistically improbable video stream, inaccurate CQ calculation, or a simple bug, but this seems to be pretty far off the mark so I thought that I might report this data incase it might help.

I suppose that I've babbled off plenty for now.

Thanks!
MKanar

[delly01]

I 'm relatively new to the subject, but imho CQ does not guarantee a certain size but a certain quality. To determine the size accurately, you have to use Tmpgenc with 2-pass-vbr just like cce.

Bye,

Detlev

[markrb]

The first error is normal and is suppose to be there. If you don't want to see it simply uncheck the warn if bitrate is to high check box on the bitrate tab.

The Checksum error is a known issue and there is a patch for it in the Q + A. On some machines it happens all the time for others not at all and still others rarely. If you get that error often you may have a timing issue in your memory. It might only be the slightest bit off and most programs wouldn't have a problem, but CCE is very finicky. If you are overclocking try slowing down. It has also been stated here that raising your ram voltage slightly can sometimes help as well.

Just as a note you may want to raise the min bitrate to 300 as some DVD players have problems with a bitrate that low. You may not always be using this player and wouldn't it suck if your brand new player won't play all those SVCD's you made.

I don't use TMpg so I can't comment on CQ, but I think delly01 is right.
Tmpg support is very new and the cd size calculations were originally made for CCE.
It could also have been that by using crash recovery instead of using Tmpg from the outset could have thrown everything way off. A file is created upon hitting the Go button and many of the settings are there to stay unless you manually edit the file on your own.

Mark

[mkanar]

Originally posted by markrb
The first error is normal and is suppose to be there. If you don't want to see it simply uncheck the warn if bitrate is to high check box on the bitrate tab.

I know that this is normal, but my point is that the 'yes' and 'no' options seem meaningless unless there is something that I am missing. I mentioned this as feedback to dvd2svcd's author.

The Checksum error is a known issue and there is a patch for it in the Q + A. On some machines it happens all the time for others not at all and still others rarely. If you get that error often you may have a timing issue in your memory. It might only be the slightest bit off and most programs wouldn't have a problem, but CCE is very finicky. If you are overclocking try slowing down. It has also been stated here that raising your ram voltage slightly can sometimes help as well.

I am not a newbie to DVD2SVCD or its forum and I am well aware of the patch that I long ago applied. As I mentioned, I am running the CPU frequency at spec, no overclocking. Finally, my RAM is already being run under-spec.

Just as a note you may want to raise the min bitrate to 300 as some DVD players have problems with a bitrate that low. You may not always be using this player and wouldn't it suck if your brand new player won't play all those SVCD's you made.

I don't use TMpg so I can't comment on CQ, but I think delly01 is right.
Tmpg support is very new and the cd size calculations were originally made for CCE.
It could also have been that by using crash recovery instead of using Tmpg from the outset could have thrown everything way off. A file is created upon hitting the Go button and many of the settings are there to stay unless you manually edit the file on your own.

I totally understand the inaccuracies of the CQ and the need for 2-pass VBR for accurate results. However, [I]I am mentioning this as feedback to potentially help DVD2SVCD's author better tune the CQ parameter's, etc as it was pretty far off in this case. As for the crash recovery, no audio or video bitrates were adjusted but I agree that there may be an issue there somewhere.

Mark

This message is almost meaningless in the newbie forum. I have probably posted 50+ messages to the DVD2SVCD forum during the past several months; what gives? This newbie/advanced user split forum thing is starting to become more of a nuisense than a benefit. ohwell....

MKanar