Scenarist Bitrate too high - a story of stupidity

For a little enjoyment, and possibly to help someone else. I am trying to backup a DVD with a DTS track. The first time I re-encoded the movie, my setting in CCE had 9800 as the MAX rate. Well scenarist complained that the combined bitrate for the track was too high (when combined with the 2ch, 6ch and DTSs tracks). So I did a little searching (great tool) and found out that I needed to reduce my setting in CCE to something smaller. I followed the post at Trilight's site and did an addition of my audio tracks (2ch=224, 6ch=448, and DTS=754) for a total of 1426. Subtracted that from 9800 and ended up with 8374. So I set my target max in CCE to 8350 (giving a little fudge room). I then re-encoded, not bothering to redo the first pass (I used the already generated .vaf file from CCE). Tried again in Scenarist, and it still complained. So I used the Tools -> Verify track to get some info. Scenarist told me ("Main video bitrate = 9800000", data="movie") ??? Hmmm, must have done something wrong. So I re-encoded again from scratch and this time I looked at the mpv (before running pulldown on it... as I heard this might mess up Bitrate viewer) and it was reported as 9800???? Hmmm, must have done something wrong again. Back to the search at Doom9. I found a suggestion that checking "DVD Compliant" makes CCE ignore your MAX rate and sets it to 9800. Well, that must be it! So.. I re-encoded again from scratch. This time.. success. Bitrate viewer says the MPV is 8350. So.. I added all my media assets back into Scenarist and created a track with just the movie file and ran the Verify Track. Well damned if Scenarist doesn't think the file is 9800. So... after taking a much needed Time-out blowing up stuff on x-box Mech Assault, I came back and tried again. "If bitrate viewer thinks the file is ok, then something must be wrong with scenarist" or "Scenarist is right and bitrate viewer is NFG". I'll try one more time... and then this is where it hit me. Each and every time, I used the first "scenchap modified" script to create a project for me. Why make a new one? After all, the media assests are named the same as they were before??? What I didn't realize was that somehow, the script contained or fudged up the info about the new files. So.. short story long, I tried creating a new scenchap modified script, and presto-change-o IT WORKED :D. Moral of the story... if you are gonna re-do something 3 times... redo all the steps. Each re-encode pass took approximately 5 hours due to needing to run DECOMB, and I used the Robshot method on each, making a total of 3 passes, each time (~15 hours x 3 = almost 2 days of encoding time, not to mention getting rid of the grey bitches). I figured out the first time that I re-encoded, that using the previous .vaf file (results from the 1 pass Q60 session) that adjusting the max bitrate after, didn't reduce the max bitrate. I had to start from scratch each time. Anyway.. just had to share.

Great useful post. I have my video ready to be encoded, and I was thinking of using CBR@9800, as it's a short video. But, it seems it won't work that way. Does anybody know of a guide to encode, author and burn DVD's from scratch?? I am not talking about rips, but original material. Basic things like, encode CBR@8000 or VBR@something... How to create menus, chapters, etc. Thanks.

Why did you need to run DECOMB on a DVD rip? This shouldn't be necessary, unless your original material was a hybrid (like ST:TNG episodes). Even so, you probably shouldn't need to run it in all passes. If I need to perform an IVTC, I dedicate one pass for this, with IVTC being the only function run in the script. I set the encoder for non-complient DVD settings with a CBR encode at ~ 9.5Mbps with a GOP structure of "IPPP". This will create a fairly large file (~4GB per hour), but you will loose very little quality from your original, and subsequent encode runs will process much faster.

Hey slk001, The source was hybrid. I've never thought of doing one pass on the original source, then the remaining passes on the result from the first pass. Interesting idea. Is there any quality loss doing it this way? Seems like there might be (although, I'm not sure). I'll have to try that on the next set that I get.