Experiencing Difficulty Using DVD RB and CCE? If So, Then Ask Your Questions Here.

Hey guys, the dvd-r i'm attempting to make with rebuilder is definitely over 4.7 GB. I ripped the dvd first with Decrypter and currently my HD VIDEO TS folder has the following files:

VIDEO TS.BUP 10 KB
VIDEO TS.IFO 10 KB
VTS_01_0.BUP 84 KB
VTS_01_0.IFO 84 KB
VTS_01_1.VOB 6,560,072 KB
VTS_01_MENU_1.VOB 0 KB
VTS_02_0.BUP 30 KB
VTS_02_0.IFO 30 KB
VTS_02_0.VOB 0 KB
VTS_02_1.VOB 10874 KB
VTS_02_MENU_1.VOB 400,950 KB

So, the first titleset VTS_01 contains the movie, and the second one VTS_02 contains the menus only. I removed some of the VOB IDs in the second titleset like the company logo etc using IFO edit - but i can preview everything with dvd shrink perfectly and can re-encode it with DVD shrink to fit 4.7 GB. Ironically, I think the rebuilder prgm is able to transcode the DVD shrink re-authored 4.7 GB version.

When I load up the above VIDEO TS folder into DVD rebuilder's source path, the VIDEO TITLE SETS BOX indicates only VTS_02 (11 MBytes, 16:9).

Is it possible to use ifoedit to remove unwanted things then use rebuilder for the transcoding to 4.7 GB. Also, will having one big VOB with the whole movie screw up DVD rebuilder, or does it only work when the movie is split into 1 GB chunks. Also, is it normal for Decrypter to create menu vobs into separate menu vob files like the ones above, or should it be incorporating the VTS_02_MENU_1.VOB within VTS_2.VOB. Could that be tripping up rebuilder.

Anyways, hope this helps

 

Hello,

I'm having the same troubles the gentleman above was having w/ RB. I'm using CCE SP w/ ECLCCCCCDFEEEEf... I got it to work properly twice, and now everytime I get that Runtime Error 9. Very frustrating too since it usually waits until late in the encoding to screw up. I also had the same error message popup before beginning the encoding process that said "Dvd is small enough to fit on DVD-5 continue anyway?" I'm curious if there are others who've had the same issue out there, and how'd they fix it. Doom9 has been down for what seems like forever, so I can't really go research there. Perhaps there's a quick fix. Thanks.

Ed

 

You are incorrectly ripping the files by changing the default settings in DVD Decrypter. DVD's do not contain 6GB files (VTS_01_1.VOB)... they are illegal. If properly ripped the directory would have several (6) 1GB files.

 

illegal? no, you can opt for no file splitting in decrypter- i am ripping in file mode, no file splitting. As for the vts_02_menu and vts_02 vobs, these are the actual menus, they contain lots of menu video to go through and scene selections, so they are large. I tried doing a DVD that was smaller than 4.7 GB with these menu vobs and the rebuilder worked fine; now with a DVD greater than 4.7 GB rebuilder won't do it. What are the ideal settings for Decrypter to avoid making menu vobs?

 

Make sure you have already learned enough about this DVD-Rebuilder before trying to teach other on how to use it.

 

Doing a little house cleaning.
_X_X_X_X_X_[small]

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." Sherlock Holmes (by Sir Arthur Conan Doyle, 1859-1930)[/small]

 

jdobbs !

If you are the author of the DVD-Rebuilder, please allow me to say hello and allow me to ask a few thing. If you are the author of this DVD-Rebuilder, the message bellow is for you. Please read on.

First, I would like to say that DVD-Rebuilder is a great program: compared to the big 3 methods, DVD-Rebuilder prevails: the re-authoring engine in DVD-Rebuilder is the most perfect one I have seen; and the convenience that this DVD-Rebuilder provides us and assists us in every aspect. And a lot more. DVD-Rebuilder is the best tool I have ever had a chance to use: and I am still using it to encode a lot of DVD films.

Again, it is a great program.

But I have rather a bit of concern the way this DVD-Rebuilder treats pure interlaced ntsc 29.976 and hybrid type video contents. Please allow me to be clear on this.
As we all know that ( please allow me to re-say this to make me more understandable ), when encoding with CCE ( or any other encoding engines ) we have to do as follows:
1. If the source content is FILM ( 95% or higher progressive film ), then we use "Forced film" feature in DVD2AVI and encode as progressive at 23.976 fps.
2. If source is contents that need to be IVTCed ( 90% or less progressive film ), we then use an IVTC process , one of such is Decomb IVTC in AviSynth as Telecide()
Decimate(cycle=5).
3. When source is HYBRID, we have to use a hybrid treatment.
4. And when source is pure INTERLACED ( 29.976 fps ), we can encode it as interlaced ( alternate_scan=true ) ( 29.976 fps ), or we can deinterlace it with a good deinterlacer ( like the SmoothDeinterlacer ) and encode it as progressive ( progressive=true ).


Here is the question that, if possible, would you please clarify for us: what engine ( algorithms ) does this DVD-Rebuilder uses to bring the 29.976 fps down to 23.976 fps: is it the same algorithm for all four video types as I had stated above: or there is a separate algoritm for each type of the video types I had stated above?

I seems that, in DVD-Rebuilder, there are ONLY TWO types of video: progressive contents and pure interlaced contents: pure interlaced contents be deinterlaced with Decomb if user chooses to deinterlace them with Decomb, and progressive contents be just encoded as progressive ( progressive=1: progressive=true ).
If the above is true, then FILM contents and contents that need to be IVTCed ( please see above the four types of video I had stated ) are treated as ONE in DVD-Rebuilder: so "Forced Film" feature being used and these two type ( FILM and contents that need to be IVTCed ) are encoded as progressive.
Also, if the above is true, then HYBRID contents and contents that are pure interlaced ( ntsc ) are treated as ONE: being deinterlaced with Decomb if the user chooses to do so, or being encoded as interlaced ( alternate_scan=true and ConvertToYUY2(interlaced=true).

If all the above are true, then, it would be reasonable to use a good deinterlacer, like the SmoothDeinterlacer with this DVD-Rebuilder.

Can you please make an option in DVD-Rebuilder so that we can specify the syntax for SmoothDeinterlacer to be used in the deinterlacig procedure: more clearly like:
An option under "Deinterlacing" as "Deinterlacing Syntax" or "Deinterlacing Editor": with this, we can specify our own deinterlacing syntax.

 

Still cleaning.
_X_X_X_X_X_[small]

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." Sherlock Holmes (by Sir Arthur Conan Doyle, 1859-1930)[/small]

 

@happyuser

You are obviously used to manually having to rebuild and deinterlace (especially for hybrid sources) using older methods (like the Big 3). In DVD Rebuilder you don't have to worry about all that. THE RESULTING OUTPUT WILL BE EXACTLY THE SAME AS THE ORIGINAL. If it is progressive, the result will be progressive. If it is interlaced, the result will be interlaced. If you have one of those (previously difficult) NTSC originals that is partially telecined and partially interlaced -- each and every frame in the output is handled exactly like the original.

The option to use DECOMB was put there for one reason only. Some people like to play their movies back on their PC and never actually burn a DVD -- and there are a lot of PC players that just look terrible playing interlaced sources.

The best strategy for most users is to not try to out-think the software and just use the default settings as they come when installed. You will get a good backup in 99.99% of all cases.

The algorithms in DVD-RB were all developed by myself -- and were designed specifically to get around all this stuff (that's the reason you don't run DVD2AVI -- I've written code myself to scan the original stream and document its form). I am in NTSC-land, and using older methods there was never a good way to convert hybrid sources -- deinterlacing has never worked that well, and as a result you ended up with a copy that could never truly match the original. The results were quirky at best. If you've ever tried to backup the STNG series discs, you'd see what I mean.

 

I think I've learned a little. ;-)

 

Don't worry about the frame rate. DVD-RB always sets the NTSC rate to 23.976 when it goes through CCE -- that's just part of the method and its necessary. The frame rate will be reset correctly during rebuild. It doesn't use force film -- as force film doesn't exist in this method (DVD2AVI isn't used -- I build the .D2V file with my own code). If your original source was interlaced -- it will also be interlaced during rebuild. The methods are based on an in-depth understanding of the internal workings of how DVD2AVI and MPEG2DEC work and it is absolutely necessary to rebuild the structure to match the original. The internal flags of the MPEG streams are also modified during rebuild, so you can't trust an examination of the .M2V files... you have to look at the final output in the .VOBs.

 

Just to clarify why this is necessary consider a hybrid source. Parts of the source are interlaced and there are 29.97 frames physically in the MPEG stream for every second -- but the stream might change to telecined input, in which there are physically only 23.976 frames in the stream for every second. When encoding in CCE you can't tell it to do some frames at one rate and others an a different rate. So by setting a common denominator of 23.976 -- you make it possible to encode it. If you played back the .M2V you'd see some sections running at normal speed and others slowed. But it really doesn't matter, because the speed can be reset in the MPEG stream during rebuild and the RFF/TFF/progressive flags corrected for proper telecining and playback.

Another point I'd like to make is related to a comment I'd seen earlier where you'd had concerns that the sampling size of DVD-RB and the fact that it encodes only a cell at a time. That doesn't hold true with proper analysis of the original stream. One of the advantages of reencoding a previously encoded stream is that you already have one-pass before you even start -- the original that was previously encoded. DVD-RB uses the bit allocation of the original stream to determine cell sizes -- so you will get output that is as good (or possibly even better) than if you encoded the entire VTS as one unit. There are also a host of other problems that get injected into the process when you try to work at a level higher than cell.

Added: Something else to consider. When you use force film on a hybrid source you are actually removing frames from the original stream in any interlaced sections (in order to bring the frame rate down to 23.976) -- that always results in a severely degraded picture and often gives terrible jerkiness in scenes that are panned horizontally. This and other anomalies were the reason I decided to do the source analysis and .D2V creation myself. The odd .M2V files are a way of bypassing these types of difficulties.

 

Understand -- I didn't mean it as a negative remark. I thought it was a good point to bring up, anyway. I had a pretty long debate with some of the folks over at Doom9 because they thought a single cell wasn't a large enough domain to get the full benefit of VBR. I'd done a lot of work to ensure that wasn't the case... and numerous tests that examined the resultant Q values of the I, P, and B output showed that using the original stream as a baseline more than compensated for the smaller VBR compression domain.

Added: Agree with you on the SP/Basic question. The difference between 2 and 3 passes certainly doesn't warrant the huge cost difference. The OPV feature of SP does sometimes come in handy (especially for processing DV sources into DVD at a fixed quality level). But there really isn't a lot of advantage (especially considering the cost difference) when using it with DVD-RB. SP is aimed at video professionals.