CBR vs Xpass VBR for Compliant SVCDs

[Wicked_Al]

I'm not trying to start a Jihad here, just need some feedback to refine my SVCD techniques.

I've been using 2pass VBR to make SVCDs so that at most I'll use 2 CDs per movie. What I've noticed is that when using VCDHelps Bitrate Calc tool the average bitrate tends to be really close to the Max if the movie is around 90min. An example, the tool calculates that at 40:24 segment with 192Kbps audio (DVD Source was 192Kbps) on an 80 Min CD suggests an average bitrate of 2487 with a max of 2528. If I were to use these settings with VBR to encode in TMPGEnc, and run it through Bitrate Viewer on the m2v, the average bitrate would be way over the max bitrate that I encoded with, around 2800. The encoded max would be around 3100. While it looks nice, I worry about compatibility with various DVD players, cause my cheapo Genica GN800 and Sony NS400 seem to have problems playing these, not to mention that the filesize is a little bigger than predicted, so I need to prey that my current blanks can handle the overburn or hunt around for 90/99 min CDRs (My burner handles them fine), but they are next to impossible to get these days.

Since the average bitrate for Xpass VBR is equivilant to the bitrate for a compliant SVCD using CBR, obviously in this case (movies that are 90 mins or less) CBR is the better way to go. What I want to know is why is TMPGEnc so high over its max and average bitrate? I recently got ahold of the Plus version, so I'll try that out tomorrow after I check the quality of ~2400 CBR, but is this a TMPGEnc problem, a problem with the Bitrate Calc tool, Bitrate Viewer, or heaven forbid a user problem?!?!? Are you guys experiencing the same thing with inaccurate average/max bitrates in TMPGEnc? I know most players can handle bitrate spikes of around 3000 in moderation, but when the average is over 2700 I'd think there is seriously compatibility problems, especially since the SVCD is no longer compliant.

Encoding params:

CVD NTSC or NTSCFilm
352x480
192/224Kbps
48KHz
Non Interlace
GOP Max 15

TMPGEnc 2.54 freebie

[adam]

I think this is a combination of several things.

First off, TMPGenc isnt completely accurate in respecting your settings. All encoders are like this but TMPGenc seems to be even worse but for the most part this only affects the max bitrate not the avg. These bitrate spikes are present even in CBR encoded video and rarely cause any problems since they are so short in duration.

Now I think the majority of the problem lies with Bitrate Viewer itself. I believe that it has some sort of problem correctly analyzing 23.976fps material with the 3:2 pulldown enabled. I'm not sure what's going on here but when I analyze 29.97fps material the results seem much more accurate. For instance when analyzing ntscfilm SVCDS I take the reported avg bitrate from Bitrate Viewer and do the math and it doesnt add up. The filesize is not as big as Bitrate Viewer's settings would suggest.

No bitrate calculator can be totally accurate because no mpeg encoder can be completely consistent. You should always use a slightly lower avg bitrate than what any bitrate calculator tells you to. If you use a program like FitCD (most accurate bitrate calculator in existence in my opinion) it lets you specify a safety margin so that you don't go over your expected filesize.

In general though, your bitrate settings will be more accurate with CBR. I wouldn't worry too much about compliancy between CBR and VBR encodes though. If your settings are reasonably under the bitrate limitations than the resulting mpg should be fine, regardless of what any bitrate viewer reports.

[Wicked_Al]

The files that I was analyzing were 23.976 with 3:2 pulldown, so that could be what the problem is. The filesizes arent that much over what they should be(+15MBs)...typically just enough to make some CDRs have playback problems, cause on a 90/99 min CDR the play just fine. I wasnt sure if it was the bitrate causing my SVCDs to play like crap or media...I guess its media.

[adam]

I have one more possible suggestion that might be worth a try. From your original post it seems like you are encoding audio and video together. I think when you do this TMPGenc may add additional overhead to the program stream which could definitey alter the filesize by up to 15mb's. As a test take one of your mpgs and demultiplex and then remultiplex and see if the filesize goes down.

[Wicked_Al]

I wouldnt be able to test that on the files I've encoded because I demux in TMPGEnc then remux with bbmpg with SVCD settings so I can get the scan offsets set. Recently I started running out of space (Imagine an 80GB hard drive not being enough) so after each step I delete the old parts. In fact, if I didnt delete the VOBs I could have done the same exact encode again. Oddly enough, I decided to encode the audio and video seperately, so everything I did last night wouldnt help me diagnose the problem. I can't say this with certainty, but I do believe that after bbmpg the file size is smaller. Not a whole lot smaller, but smaller than it was.

Later on tonight after I install another 80GB hard drive I'll encode exactly 40 minutes of some 23.976 (3:2 pulldown) movie with the audio and a 29.97 movie and see what the averages are like using 2 pass VBR.

[adam]

Ahh, well the scan offsets add about 15-20MB's of extra overhead so I think this must be whats causing your file to go over your predicted size. I'm fairly certain that the vcdhelp java bitrate calculator does not take into account the SVCD scan offsets. Again I have to recommend that you use FitCD if you want to get your predicted filesize exactly correct. It allows you to set whether or not you allign sequence headers and add SVCD scan offsets and it makes the appropriate adjustments in its predictions.