How do you make cce (dvd compression) to work?

[nautilus7]

Over the last 6 months, i 've tried to compress 5~6 different dvds using cce (1-pass vbr & multipass vbr)(using the ifoedit guide in doom9's site). ALWAYS the same error in the muxing process: exceeding bitrate. Every time i examine the m2v stream with bitrate viewer and i always find a spike over the max bitrate i set in cce, but not too high to exceed the dvd's max allowed bitrate (in combination with the audio etc.)

In all cases, i was trying to mux 1 video stream, 1 audio steam and 1 or 2 subtitles streams. I believe all the steps that i'm doing are correct (gdindex ->avs ->cce ->mux). I have spent several days reading this forum at this time, change a lot of options (trying to make it work), but nothing.

I tried many cce (and other tools) versions, lowering the max bitrate to 8500, changing several muxing programs, but no result.

What is going wrong? HELP ME please!!!!

[neuron2]

Your title violates forum rule 9 and your last sentence does not sufficiently obscure the profanity, which violates rule 4. Please correct them both.

[nautilus7]

Ok, i fixed them... Would you help now?

By the way, neuron2, does your dgindex reports the correct audio delay (when demuxing audio)? Why does the delay value differ from the one dvd decrypter reports? I did a search and i found many results, but didn't come to a conclusion...

[neuron2]

Would you help now? I would if knew anything about the problem.

By the way, neuron2, does your dgindex reports the correct audio delay (when demuxing audio)? Why does the delay value differ from the one dvd decrypter reports? I did a search and i found many results, but didn't come to a conclusion... It depends on where the utility decides to start outputting the streams. E.g., does the utility discard everything before the first I picture. Without knowing the internals of DVD Decrypter, I cannot tell you specifically the reason for the difference. But they can both be correct, as I said, it depends on how they start outputting the streams.

What magnitude of difference are you seeing?

[nautilus7]

See here (http://forum.doom9.org/showthread.php?t=106452) and here (http://forum.doom9.org/showthread.php?t=111689)

Why does the authoring process complete when removing the subs?

So, if we suppose that it starts from frame #3, how does this reflect to the delay in milli sec?

In the last dvd i deal with, it was -8 ms (dgindex) and -88 ms (dvd dectypter).

[Trahald]

Why does the authoring process complete when removing the subs?well.. there are a few reasons.. if there is an issue with the subtitle file it can cause erroneous buffer underflow warnings. also subtitles do have overhead.. although its very small and usually wont put you over the edge even when they arent considered into bitrate. where did you get your subs from and/or how did you make them.. by what process?

[nautilus7]

The subtitles are in .sup format, created by vobedit (ripped from dvd).

[nautilus7]

***************

[hank315]

Some hints:
- Don't trust the outcome of Bitrate Viewer too much, it will give you a global view of the bitrate only, it's useles to detect bitrate spikes.
- CCE is a very good encoder but it can easily overshoot the max. bitrate set.
- You 'lowered' the max bitrate to 8500, IMHO this is still very high if you're using CCE, see previous points.

[nautilus7]

Thanks a lot for your response.

I will try 8000 kbps or lower to see what happens.
If i use your encoder instead of cce, will i get the max bitrate i want, or i wll have spikes too? Where your encoder stands compared with cce regarding quality?

[nautilus7]

I tried something different. I demuxed all streams (video, audio and subs) from the original dvd and then imported them to muxman, to see what happens. Surprise: I got the usual error "exceeding bitrate". So, the original - uncompressed video has a max bitrate that muxman (and other authoring tools) can't deal with, but still within the dvd rules. What's wrong?

Here is the typical log i get every time with any dvd i try:

Accepted audio F:\DVD rips\SYRIANA\VIDEO_TS\VTS_01_1.80.ac3
Opened sub 1 file F:\DVD rips\SYRIANA\VIDEO_TS\VTS_01_1.25.sup.
Opened sub 2 file F:\DVD rips\SYRIANA\VIDEO_TS\VTS_01_1.20.sup.
expanded database to 300 entries.

11:59:37 Begin multiplex VTS01.
Title Segment List
Segment_1 non-seamless
Encoded stream 20 is script stream 1.
Encoded stream 21 is script stream 2.
Buffering audio track 1 file F:\DVD rips\SYRIANA\VIDEO_TS\VTS_01_1.80.ac3.
Maximum audio duration 347764 fields.
Positioned F:\DVD rips\SYRIANA\VIDEO_TS\VTS_01_1.m2v to 00:00:00:00
Starting scene Segment_1_scn1 at 00:00:00:00
Starting scene Segment_1_scn2 at 00:01:38:22
Starting scene Segment_1_scn3 at 00:05:44:22
Starting scene Segment_1_scn4 at 00:09:22:15
Starting scene Segment_1_scn5 at 00:15:08:24
Starting scene Segment_1_scn6 at 00:20:26:22
Starting scene Segment_1_scn7 at 00:25:00:18
Starting scene Segment_1_scn8 at 00:27:33:05
Starting scene Segment_1_scn9 at 00:31:45:04
Starting scene Segment_1_scn10 at 00:36:38:12
Starting scene Segment_1_scn11 at 00:41:30:11
Starting scene Segment_1_scn12 at 00:43:58:00
Starting scene Segment_1_scn13 at 00:47:16:20
Starting scene Segment_1_scn14 at 00:50:09:09
Starting scene Segment_1_scn15 at 00:54:27:00
Starting scene Segment_1_scn16 at 00:58:57:19
P-STD buffer underflow by 18045 bytes at 333356492, sector 1423733.
P-STD buffer underflow by 37628 bytes at 333360092, sector 1423757.
P-STD buffer underflow by 20668 bytes at 333363692, sector 1423782.
P-STD buffer underflow by 20304 bytes at 333367292, sector 1423807.
P-STD buffer underflow by 31759 bytes at 333381692, sector 1424417.
P-STD buffer underflow by 19648 bytes at 333385292, sector 1424417.
P-STD buffer underflow by 16008 bytes at 333388892, sector 1424417.
P-STD buffer underflow by 38948 bytes at 333392492, sector 1424417.
P-STD buffer underflow by 884 bytes at 333446492, sector 1424618.
P-STD buffer underflow by 11372 bytes at 333720092, sector 1426429.
P-STD buffer underflow by 19748 bytes at 333723692, sector 1426429.
P-STD buffer underflow by 36920 bytes at 333727292, sector 1426429.
P-STD buffer underflow by 17912 bytes at 333730892, sector 1426429.
P-STD buffer underflow by 18112 bytes at 333734492, sector 1426429.

[Hemmo]

The subtitles are in .sup format, created by vobedit (ripped from dvd).

Try PgcDemux.exe for demux sups. I had have better luck with it than vobedit. No buffer underflows.

[hank315]

I tried something different. I demuxed all streams (video, audio and subs) from the original dvd and then imported them to muxman, to see what happens. Surprise: I got the usual error "exceeding bitrate". So, the original - uncompressed video has a max bitrate that muxman (and other authoring tools) can't deal with, but still within the dvd rules. What's wrong?
I also tried this with Syriana (PAL, R2)
Demuxed the uncompressed main movie with PgcDemux, muxed it using MuxMan with one audiostream and two subs:


MuxMan version 0.15P
Accepted video D:\demux\VideoFile.m2v size = 1021888356
Accepted audio D:\demux\AudioFile_80.ac3
Opened sub 1 file D:\demux\Subpictures_24.sup.
Opened sub 2 file D:\demux\Subpictures_25.sup.

16:40:43 Begin multiplex VTS01.
Title Segment List
Segment_1
Encoded stream 20 is script stream 1.
Encoded stream 21 is script stream 2.
Maximum audio duration 367480 fields.
Starting scene Segment_1_scn1 at 00:00:00:00
End of video file
Bytes remaining in buffer = 0.
Bitrate - avg: 6292467, min: 518826 (lba 0), max: 9639253 (lba 1349976).
Shortest GOP has 2 fields, longest GOP has 30 fields.
Fields: 367480, VOBU: 12248, Sectors: 2822700.

16:51:06 Begin multiplex VMG.
16:51:06 End multiplex.


No problems, I guess Hemmo is right...

[nautilus7]

I wish you guys are right. I 'll try it soon.

[nautilus7]

YESSSSSSSSSSSSSSSSSSSS!!!

It worked!!! You guys (hemmo & hank) are my heroes!!!

Vobedit sucks! Pgcdemux did its miracle!

[Trahald]

@nautilus7
i pmd you this but since you missed it i will post in the open forum. while it can be frustrating to not have your question answered, this is an open community in which noone gets paid. please delete reply #8. it is off topic and not helpful to anyone.

there are 97k+ registered people in the forum , there are never 97,000 answers to questions. usually answers are given by 1 or 2 people. but they are part of forum.doom9.org community so the whole community accepts your thanks. and yes.. hemmo and hank are awsome :)

btw.. finding solutions are a PROCESS... hemmo wouldnt have known to suggest pgcedit if i had not asked you what product you used to make the subs.

[nautilus7]

I 'm sorry for the pm, i didn't see it.

[Trahald]

np.. thank you :)