Incredible quality - The Departed with CCE OPV

[AGKnotUser]

I did Eragon R1 with both CCE SP and SP2 OPV without any problems. I rip the movie with RipIt4Me 1.7.1.0.

Hmmm, that's what I used. Maybe I got a bad disk. Anyone else tried it?

[Fishman0919]

Hmmm, that's what I used. Maybe I got a bad disk. Anyone else tried it?


Try it with 2-pass.. see if that fails... then you will know if it's a bad disc/rip

[AGKnotUser]

Try it with 2-pass.. see if that fails... then you will know if it's a bad disc/rip

I tried it with 4 pass and it worked.

[Fishman0919]

When I did this movie with OPV I kept both DD and DTS track... I just rerun it again in "Movie Only" mode keeping only DD track and CCE SP and SP2 crash at V05000900001010... bitrate for that segment is over 5500k

[dynamis]

hi all. i've been waiting five days to post this, so here goes.

i just want to make sure i understand all this correctly. concerning OPV in most cases:

1. if Q factor < ~30 (let's say, 18) the result of OPV should be comparable to multi-pass (3 or 4 passes). a clean source will help :)

2. the perceived image quality of the result should very similar or even go as far as being indistinguishable from the original source?

3. if Q factor > ~30 (let's say, 40) the result of OPV should be noticibly different from the source, exhibiting new artifacts, fuzziness, etc that are hard not to notice?

4. would multipass make things any better in this case? my guess is no or very little.

5. if quality is noticibly bad, one can, remove unwanted content, use matrices, split into two discs or burn to DL to get better quality.

6. if i get OPV and multipass (3 or 4 passes) outputs of almost the same size (4.36GB). should the perceived quality of the results be pretty much the same for Q factor=18? for Q factor=40?

i know there's a lot of subjective stuff in here, but every bit of info and every opinion will help.

:thanks:

[jdobbs]

The OPV quality is going to be similar to the multiple pass encoding -- no matter what Q is selected. The Q is selected based upon what is needed to meet output size requirements. What you'll find is that if a Q is high, the quantization in a multipass encode will also be high.

The downside to OPV is it's limited output size accuracy. When you do a prediction, you are doing a "best guess" as to what Q is needed to meet sizing requirements. It works a lot like multipass -- but multipass does a 100% first pass (making the output prediction very exact) -- OPV does a series of 2% passes, making output prediction less accurate. Where OPV gets tough is in the granularity of setting Q factors. When Q factors get smaller, single increments can make extreme differences in sizing... so it may not be physically possible to get close to the target size. In that case, multiple passes will probably do better -- because it utilizes that lost space. Some people get around that by doing a different Q prediction for each segment -- making sizing accuracy a little better. But in my opinion that also detracts from the quality of playback -- because you will notice quality differences between the segments. Ideally the entire movie should be encoded with the same Q.

It's a trade-off... accuracy in sizing for encoding speed. For those people who get wrapped around the axle over a couple hundred wasted megabytes -- OPV is probably a bad idea. It isn't unusual at all to get a 4.10GB output size for an OPV DVD. Frankly, though, the true visually noticable effect of that unused space is pretty insignificant.

[nashcity]

For me, its isn't the reduced encoding time that makes OPV my method of choice. Actually, the encoding part is less important that the prepare phase for me. I use the OPV analysis to see what Q factor I'm working with so I can make decisions regarding the amount of space I want to dedicate to extras (audio tracks, features). You'll get a much better indication of the picture quality you're working with as opposed to using compression % as the determining factor. For example, did you know that the "Fight Club" compression % was around 63%, but the Q-Factor was 5! That basically means that the picture at 63% compression will look virtually identical to the untouched video. What that tells me is that if there were some extras that I really wanted on the DVD9, I could probably keep some of them without sacrificing a significant amount of picture quality.

As for the OPV encoding, my eyes have told me that encoding with this method has resulted in comparable picture quality to multipass, half the time its actually better, but it hardly ever worse. But that's just me. I actually found the OPV encode of King Kong (Peter Jackson's) BETTER than the 6-pass encode I compared it to. I was amazed. I remember the bitrate for that movie only being around 2700 after encode.

I usually end up with a size between 4.25-4.40 g. If you're over, just run it through dvdshrink if its only a matter of a couple hundred mbs. If you're under, don't worry about it, or use rbopt to change the q-value after the prepare phase and try your luck again.

Hope this helps. Good luck.

[manolito]

@nashcity
I couldn't have said it any better. I have been using CCE's OPV method for a very long time with DVD2SVCD and the D2SRoBa plugin. When your target is SVCD, every byte counts. But still I could never really tell a difference between OPV and Multipass VBR, even if the OPV encode was undersized maybe by about 5%.

In theory the multipass VBR method could have some advantages, though. This is from the CCE 2.67 manual:
The reason of the movement of quantization scales in Fig. A.18
and Fig. A.19 is there are severe bitrate conditions. But why is the
movement of quantization scales in Fig. A.16 ? To keep the same
image quality, should the quantization scales not be constant ?
Theoretically yes, but actually, image distortion is more visible in
simple scene than that in complex scene. So Cinema Craft Encoder
SP changes the quantization scales so that one can feel the distortion
is constant for each scenes.

However, the feeling of distortion is subjective to the certain extent
and there may be a difference of this feeling. To compensate this difference,
Cinema Craft Encoder SP provides another parameter named
bias only for multipass VBR4. By changing this parameter, you can
change the characteristics of rate control of Cinema Craft Encoder
SP.
This means that the "Q-value" is just a mathematical representation of "Quality". The human visual perception is different. Distortion in static scenes is much more noticeable to the human eye than distortion in complicated scenes. In VBR mode CCE tries to compensate this by taking away bitrate from complicated scenes and giving it to static scenes instead. And the "Bias" parameter (it is called V/C in later versions of CCE) gives the user some control over this process. This parameter has no effect in OPV mode.

Having said this I still stick to OPV for most of my encodes. Half the time and same quality is something I just cannot resist...

Cheers
manolito

[superuser]

so can it be a true statement, multipass is better way to go thn going with OPV when using filters sp. to get higher compression. As there is a possibility of the size corrections in multipass, which is not the case in OPV?

[Mugeb]

Hi everyones !

My 1st post here.

I wondered if CQ 6,5 is a good result using HC ?

Thanks.

[jdobbs]

Yes. CQ works on a different scale than Q. The scale goes from 0-32. Anything under 10 is usually pretty good.

[Mugeb]

Thanks you.

But there's something strange, I've no sound when I play my encoded movie.

Why ? :confused:

[Rippraff]

http://forum.doom9.org/showthread.php?t=123814
http://forum.doom9.org/showthread.php?t=122987
...

[writersblock29]

@superuser

Qouted:"so can it be a true statement, multipass is better way to go thn going with OPV when using filters sp. to get higher compression."

You can use filters pretty well with OVP, but you might find yourself prone to oversizing depending on what filters you use. I've always found the Undot().Deen() combination to yield in oversized projects... probably since you get an artificially lower Q value when using them. I'd stick with multipass if using filtration.

"As there is a possibility of the size corrections in multipass, which is not the case in OPV?"

Multipass is nearly always going to be dead-on, since 100% of the video content has been analized during the first pass. OVP only looks at a percentage, which is where the hit-and-miss problem comes from. Undersizing while using multipass is usually because CCE reaches a Q value of 1--which is as good as the encoder can make it, and CCE won't artifically inflate the file size past this point. This, of course, is assuming all of Rebuilder's settings are at default, and the targetsectors option hasn't been toyed with. Q values affect both OVP and multipass in that once you hit a value of 1, CCE doesn't try to outdo itself by adding un-needed bits to the project. If all 4.32GB are needed to reach a value of 2, so be it. But if only, say, 4.10GB is needed for a Q value of 1, that's the size you'll get in the final project. However, if doing full-disk copies, multipass nearly always fills the disk since everything on that disk will have different Q values. I haven't run into any yet that all Q'ed out to a value of 1 all the way through.

[chickenmonger]

Thanks you.

But there's something strange, I've no sound when I play my encoded movie.

Why ? :confused:

Missing audio seems to be a common sign pointing to a hacked professional version.

If you have purchased the professional version, then I'm not certain why the audio would be missing.

[Kool3ds]

But guyz how to use CCE SP2 with DVD REbuilder? Help appreciated.

[Fishman0919]

But guyz how to use CCE SP2 with DVD REbuilder? Help appreciated.


CCE SP2 only works with DVD-RB Pro. DVD-RB Pro with auto detect CCE SP2 being installed and the option will be available. DVD-RB (freeware) version is not compatible with CCE SP2.

[Sharc]

You can use filters pretty well with OVP, but you might find yourself prone to oversizing depending on what filters you use. I've always found the Undot().Deen() combination to yield in oversized projects... probably since you get an artificially lower Q value when using them.

That would suggest to
- run the Q anlysis using RB-Opt with the default matrix and without filters
- then select the new matrix and add filters by means of RB-Opt
- keep the calculated Q with "Set Custom Q" Set to ....
- Save Settings.

This should actually prevent oversizing due to changing the matrix or due to adding filters in OPV mode.

[superuser]

thnxs writersblock29 for ur explanation.

That would suggest to
- run the Q anlysis using RB-Opt with the default matrix and without filters
- then select the new matrix and add filters by means of RB-Opt
- keep the calculated Q with "Set Custom Q" Set to ....
- Save Settings.

This should actually prevent oversizing due to changing the matrix or due to adding filters in OPV mode.

but up here one is depending greatly on Q analysis phase and how acurately those predictions are. If there are multiple filters such as tweak, resize, denoiser, sharpner used it can increase sizing risk factor in OPV but multi-pass should sail through in this scenerio, as if every current each pass it is making full use of values learned in previous pass. may be jdobb and RB-Opt author can fill in more on this.

[dynamis]

The OPV quality is going to be similar to the multiple pass encoding -- no matter what Q is selected. The Q is selected based upon what is needed to meet output size requirements. What you'll find is that if a Q is high, the quantization in a multipass encode will also be high.

The downside to OPV is it's limited output size accuracy. When you do a prediction, you are doing a "best guess" as to what Q is needed to meet sizing requirements. It works a lot like multipass -- but multipass does a 100% first pass (making the output prediction very exact) -- OPV does a series of 2% passes, making output prediction less accurate. Where OPV gets tough is in the granularity of setting Q factors. When Q factors get smaller, single increments can make extreme differences in sizing... so it may not be physically possible to get close to the target size. In that case, multiple passes will probably do better -- because it utilizes that lost space. Some people get around that by doing a different Q prediction for each segment -- making sizing accuracy a little better. But in my opinion that also detracts from the quality of playback -- because you will notice quality differences between the segments. Ideally the entire movie should be encoded with the same Q.

It's a trade-off... accuracy in sizing for encoding speed. For those people who get wrapped around the axle over a couple hundred wasted megabytes -- OPV is probably a bad idea. It isn't unusual at all to get a 4.10GB output size for an OPV DVD. Frankly, though, the true visually noticable effect of that unused space is pretty insignificant.

hi, jdbobbs, thanks for the reply. well, the filesize i get is usually 4.27-4.37, so that's good enough for me. all i care about is getting consistently good quality for the whole movie and a viewing experience i can barely distinguish from that of the original. if i can save some time, great! but i want to get all the facts so i don't end up backing up my collection more than once :mad:

i try to remove as much as i can (extras, trailers, languages, etc.) before i begin. then i run rb-opt and see what Q values i get and do that Check Quality thing. if quality looks bad (happens to me usually when Q is in the 40's and 50's), i try removing more content or just slap it on a dual layer and move on.

is filesize the only drawback? you mentioned that in OPV each segment will have a different Q. how much of an effect will this have on quality?

also, are there any special settings (like with vbr_bias and qual_prec) one should use for anime and CG discs? i've played around with some matrices, but the result looked worse than without matrices.

thanks.

[jdobbs]

you mentioned that in OPV each segment will have a different Q. how much of an effect will this have on quality? Not in the way DVD-RB does it... that's why I mentioned it. DVD-RB applies the same Q to all segments. I think, though, that RB-Opt may have an option to do it the other way (not sure)... but I wouldn't recommend it.

[sockeye]

Perhaps a little out of the topic:

I got the following sequence for the Q factor estimates for CCE OPV:

- Analyzing VTS_02 for optimal Q factor.
-- TargetSize (sectors):1'925'519
-- Sampling 4272 of 213290 frames.
-- Predicted size (sectors) at Q=28: 2'233'483
-- Predicted size (sectors) at Q=34: 2'010'761
-- Predicted size (sectors) at Q=36: 1'950'711
-- Predicted size (sectors) at Q=168: 813'840
-- Predicted size (sectors) at Q=102: 1'048'460
-- Predicted size (sectors) at Q=69: 1'325'433
-- Predicted size (sectors) at Q=52: 1'570'777
-- Predicted size (sectors) at Q=37: 1'922'516
- Q Value selected: 37

Just wondering why the algorithm jumped from Q=36 (which was very close to the target size) to Q=168, and from there stepping down to the final value of 37.

I get the same sort of big jumps with HC OPV mode as well.

That's odd, indeed. I'll have to take a look at it.

HC? I thought I'd changed that to a simple binary search for the Q... don't know how that could jump around?

@jdobbs
Was curious if you had uncovered anything with this oddity.
This is from a HC OPV encode.
At 2.9 the target sector was almost nailed, but the next sampling went very high adding 4 additional pass to get back to 3.0.
Not a big deal, but it added several min. to the preparation phase.

[jdobbs]

Sorry, but no -- I haven't looked at it yet.

[jdobbs]

Ok. I see what's causing this. I'll make changes for the next release.

[sockeye]

Ok. I see what's causing this. I'll make changes for the next release.

Wow jdobbs, that's awsome support. :thanks:

[Voodoochild]

I backed up this movie including The Extras (alternate endings), compression was 73%.

I did 1 pass OPV (q=14 for movie, q=10 for Extras), it took only 1 hr 20 4.20GB and when I looked at it couldn't tell the difference with the original, not when looking and not when comparing shots with dgIndex, AMAZING, AMAZING...
I'm using DVD-RB for more then a year and every project I learn something new... well almost every :).

Only thing I would happy to get even though there probably no demand for it is scheduler. Summer is almost here In Israel and I want to do my backups at 5AM when it's cooler.. I know it's off topic.. But the first part is.

10x Elad

[jdobbs]

By "scheduler" do you mean something like adding a "start at" time to the batch processor?

[setarip_old]

More as a general observation, regardless of conversion process used:

It seems that with more and more DVDs being based on "mastered in high definition", the resultant conversions are of higher quality and suffer less with higher compression...

[writersblock29]

@setarip_old

"It seems that with more and more DVDs being based on "mastered in high definition", the resultant conversions are of higher quality and suffer less with higher compression... "

I couldn't agree more; I noticed this back when DVD2One was brand new, and I'd used it to back up a few "Superbit" movies. Even a film like Black Hawk Down looked incredible given the reduction in filesize. Sure, if you viewed them side-by-side you'd know the difference... but the higher the source's quality, the more forgiving they seem to be no matter what method you go by.

[Voodoochild]

By "scheduler" do you mean something like adding a "start at" time to the batch processor?

Yes so one can start encoding in 0500AM something like that... So CPU won't get so hot.

10x Elad

[EVH5150]

I've been encoding some LONG movies recently with the new HC 0.20.0.0, and I've been absolutely amazed at the quality. You should give that a try as well, maybe you can one-up CCE OPV... :)


Kagemusha (Criterion Collection), 3:00:23 runtime.
Matrix used was "6-Medium_Low(2500_3200)" from Rebuilder Matrix Editor:

Original DVD9
http://img340.imageshack.us/img340/1709/kagemushacaptureau6.th.png (http://img340.imageshack.us/img340/1709/kagemushacaptureau6.png)

49.9% compression @ 2,662Kbs with HC 0.20
http://img341.imageshack.us/img341/8323/kagemushacapturehczw1.th.png (http://img341.imageshack.us/img341/8323/kagemushacapturehczw1.png)

Original DVD9
http://img80.imageshack.us/img80/2924/kagemushacapture2ht0.th.png (http://img80.imageshack.us/img80/2924/kagemushacapture2ht0.png)

49.9% compression @ 2,662Kbs with HC 0.20
http://img80.imageshack.us/img80/813/kagemushacapture2hclk9.th.png (http://img80.imageshack.us/img80/813/kagemushacapture2hclk9.png)


(pics horizontally resized with LanczosResize)
That looks like a really stunning job by DVD-RB! Perhaps some of you guys can help me, as I'm a DVD-RB noob.

I've been trying to compress a very large movie (actually, Disc Two of the Led Zeppelin 2-disc release, Region 1), and have been having nowhere near the success that kumi got with the above screenshots. I want to keep everything on the disc, and obviously, I understand that by not removing things like the DTS track, I'm limiting the myself to poorer quality video.

In any case, I ran DVD-RB (free version) the other day, using the slowest method of the HC encoder. Compression from this DVD-9 to DVD-5 was 55%, which I know is huge. But still, I was surprised to see that the quality I got from DVD-RB was little better than performing the exact same job with DVD Shrink. Also, DVD Shrink took around three hours to do it, yet DVD-RB with HC Encoder took over five. Here is the the logfile from the DVD-RB encode:

[01:37:18] One Click encoding activated...
-----------------
[01:37:19] Phase I, PREPARATION started.
- VTS_02: 84,229 sectors.
-- Scanning and writing .D2V file
-- Processed 9,550 frames.
-- Building .AVS and .ECL files
- VTS_03: 94,303 sectors.
-- Scanning and writing .D2V file
-- Processed 8,688 frames.
-- Building .AVS and .ECL files
- VTS_04: 60,115 sectors.
-- Scanning and writing .D2V file
-- Processed 6,830 frames.
-- Building .AVS and .ECL files
- VTS_06: 55,871 sectors.
-- Scanning and writing .D2V file
-- Processed 4,358 frames.
-- Building .AVS and .ECL files
- VTS_07: 3,391,046 sectors.
-- Scanning and writing .D2V file
-- Processed 226,116 frames.
-- Building .AVS and .ECL files
- VTS_08: 82,311 sectors.
-- Scanning and writing .D2V file
-- Processed 7,515 frames.
-- Building .AVS and .ECL files
- VTS_11: 40,445 sectors.
-- Scanning and writing .D2V file
-- Processed 3,754 frames.
-- Building .AVS and .ECL files
- VTS_13: 54,365 sectors.
-- Scanning and writing .D2V file
-- Processed 6,210 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 24.5%
- Overall Bitrate : 892Kbs
- Space for Video : 1,239,416KB
- HIGH/LOW/AVERAGE Cell Bitrates: 1,181/600/892 Kbs
[01:44:24] Phase I, PREPARATION completed in 7 minutes.
[01:44:24] Phase II ENCODING started
- Creating M2V for VTS_02 segment 0
- Creating M2V for VTS_02 segment 1
- Creating M2V for VTS_02 segment 2
- Creating M2V for VTS_03 segment 0
- Creating M2V for VTS_03 segment 1
- Creating M2V for VTS_04 segment 0
- Creating M2V for VTS_04 segment 1
- Creating M2V for VTS_06 segment 0
- Creating M2V for VTS_06 segment 1
- Creating M2V for VTS_07 segment 0
- Creating M2V for VTS_07 segment 1
- Creating M2V for VTS_07 segment 2
- Creating M2V for VTS_07 segment 3
- Creating M2V for VTS_07 segment 4
- Creating M2V for VTS_07 segment 5
- Creating M2V for VTS_07 segment 6
- Creating M2V for VTS_07 segment 7
- Creating M2V for VTS_07 segment 8
- Creating M2V for VTS_07 segment 9
- Creating M2V for VTS_07 segment 10
- Creating M2V for VTS_07 segment 11
- Creating M2V for VTS_07 segment 12
- Creating M2V for VTS_07 segment 13
- Creating M2V for VTS_07 segment 14
- Creating M2V for VTS_07 segment 15
- Creating M2V for VTS_07 segment 16
- Creating M2V for VTS_07 segment 17
- Creating M2V for VTS_07 segment 18
- Creating M2V for VTS_07 segment 19
- Creating M2V for VTS_07 segment 20
- Creating M2V for VTS_07 segment 21
- Creating M2V for VTS_07 segment 22
- Creating M2V for VTS_08 segment 0
- Creating M2V for VTS_08 segment 1
- Creating M2V for VTS_11 segment 0
- Creating M2V for VTS_11 segment 1
- Creating M2V for VTS_11 segment 2
- Creating M2V for VTS_11 segment 3
- Creating M2V for VTS_13 segment 0
- Creating M2V for VTS_13 segment 1
[06:46:26] Phase II ENCODING completed in 302 minutes.
[06:46:26] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_02
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Rebuilding segment 2 VOBID: 1 CELLID: 3
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_02_0.IFO
- Updating TMAP table...
- Processing VTS_03
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_03_0.IFO
- Updating TMAP table...
- Processing VTS_04
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_04_0.IFO
- Updating TMAP table...
- Processing VTS_06
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_06_0.IFO
- Updating TMAP table...
- Processing VTS_07
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Rebuilding segment 2 VOBID: 1 CELLID: 3
- Rebuilding segment 3 VOBID: 1 CELLID: 4
- Rebuilding segment 4 VOBID: 1 CELLID: 5
- Rebuilding segment 5 VOBID: 1 CELLID: 6
- Rebuilding segment 6 VOBID: 1 CELLID: 7
- Rebuilding segment 7 VOBID: 1 CELLID: 8
- Rebuilding segment 8 VOBID: 1 CELLID: 9
- Rebuilding segment 9 VOBID: 1 CELLID: 10
- Rebuilding segment 10 VOBID: 1 CELLID: 11
- Rebuilding segment 11 VOBID: 1 CELLID: 12
- Rebuilding segment 12 VOBID: 1 CELLID: 13
- Rebuilding segment 13 VOBID: 1 CELLID: 14
- Rebuilding segment 14 VOBID: 1 CELLID: 15
- Rebuilding segment 15 VOBID: 1 CELLID: 16
- Rebuilding segment 16 VOBID: 1 CELLID: 17
- Rebuilding segment 17 VOBID: 1 CELLID: 18
- Rebuilding segment 18 VOBID: 1 CELLID: 19
- Rebuilding segment 19 VOBID: 1 CELLID: 20
- Rebuilding segment 20 VOBID: 1 CELLID: 21
- Rebuilding segment 21 VOBID: 1 CELLID: 22
- Rebuilding segment 22 VOBID: 1 CELLID: 23
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_07_0.IFO
- Updating TMAP table...
- Processing VTS_08
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_08_0.IFO
- Updating TMAP table...
- Processing VTS_11
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Rebuilding segment 2 VOBID: 1 CELLID: 3
- Rebuilding segment 3 VOBID: 1 CELLID: 4
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_11_0.IFO
- Updating TMAP table...
- Processing VTS_13
- Reading/processing TMAP table...
- Rebuilding segment 0 VOBID: 1 CELLID: 1
- Rebuilding segment 1 VOBID: 1 CELLID: 2
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_13_0.IFO
- Updating TMAP table...
Correcting VTS Sectors...
[07:02:18] Phase III, REBUILD completed in 16 minutes.

Done.
[07:02:18] PREPARE/ENCODE/REBUILD completed in 325 min.

On both Shrink and DVD-RB compressions, there were major compression artefacts, almost blocking-type effects. Given that kumi and others have had so much success with long movies, is there anything that I can do to improve the quality of this movie, while keeping all the extras etc intact? I'm certain that, given the results of others, that there must be a way!

I've been reading many threads about using different matrixes. I'll need a dumbed-down version of how to employ these, I think!


Thanks!


EVH

[Rippraff]

Compression from this DVD-9 to DVD-5 was 55%, which I know is huge.
Not in your example below:
- Reduction Level for DVD-5: 24.5%
- Overall Bitrate : 892Kbs
- Space for Video : 1,239,416KB
- HIGH/LOW/AVERAGE Cell Bitrates: 1,181/600/892 Kbs

Sorry to say I doubt there will be any possibility to get an acceptable result with this disc, if you want to keep everything (especially the DTS stream).
Better to take a DVD-9 in this case.

Cu Rippraff

[EVH5150]

Not in your example below:

Sorry to say I doubt there will be any possibility to get an acceptable result with this disc, if you want to keep everything (especially the DTS stream).
Better to take a DVD-9 in this case.

Cu Rippraff
Thanks for the reply. I guess I am just surprised that my DVD-RB encoded DVD-5 doesn't look that much better than my Shrink-transcoded DVD-5. Also, because Disc One of the original DVD-9 (at 8,007,994KB as opposed to Disc Two's 8,303,012KB), came out in Shrink rather well, all things considered, and that was with DTS tracks etc too.

Still, there must be some filters/matrixes which deal with these exceptionally-low high compression levels. Are there any that are worth trying (even if they are just for the benefit of my own experience)?

Thank you!

[Rippraff]

Thanks for the reply. I guess I am just surprised that my DVD-RB encoded DVD-5 doesn't look that much better than my Shrink-transcoded DVD-5.
Maybe because you have a huge menu as well. Shrink can compress it, RB Free can't.

Still, there must be some filters/matrixes which deal with these exceptionally-low high compression levels. Are there any that are worth trying (even if they are just for the benefit of my own experience)?

Different matrices can only be used with the Pro version.
Again take a look at this:
Space for Video : 1,239,416KB
This means, more than 3 GB can't be handled by RB free cause it's either menu or audio streams.
You can get a little improvement by adding
vts_min_size=1 under [Options] in Rebuilder.ini but you won't get a good video quality with dts streams.

Cu Rippraff

[archaeo]

@EVH5150
I backed up my same LZ 2 disc series, and the problem is definitely with the DTS audio - it's huge. The only acceptable video quality I got was when I deleted the DTS track. Unforunately it is critical to the enjoyment of the film. Without it, there is a significant loss of much of the low end sound, and it just doesn't work for me. It's one of those that is best to back up to DVD9.

[EVH5150]

Thank you very much for both of your replies. This is helping me to understand the program (and I might just have to upgrade to Pro ;) )

[Rippraff]

(and I might just have to upgrade to Pro ;) )
That's always a good idea. ;)

Cu Rippraff

[tom942]

I've got a question about OPV.

I've been doing test with CCE and using the matrix SONY 127 MEDIUM that manono posted some time ago, I've got a Q=40.

If I use AVAMAT6, I've got a Q=17.

My question is if SONY's matrix gives me a higher Q because it tries to retain more detail than AVAMAT with the risk of obtain artifacts in the encode?.

[Sharc]

Basically yes. A higher Q means higher quantization which tends towards more artefacts. I have no experience with the SONY matrix though, but I would assume that its coefficients are lower than avamat, hence retaining more detail.
Avamat 6 results in very low Q values without loosing much detail - at least I would assume you wouldn't notice any loss of details when watching the movie.

Still, as long as Q is below 40, artefacts are barely visible (see also CCE manual). It depends on your eyes and taste if you prefer the avamat or SONY encode, IMO.

[tom942]

Here it is SONY 127 MEDIUM:

08 12 13 14 15 16 19 22
12 13 14 15 16 19 22 26
13 14 15 16 19 22 26 32
14 15 16 19 22 26 32 41
15 16 19 22 26 32 41 53
16 19 22 26 32 41 53 70
19 22 26 32 41 53 70 94
22 26 32 41 53 70 94 127
12 12 13 14 15 16 19 22
12 13 14 15 16 19 22 26
13 14 15 16 19 22 26 32
14 15 16 19 22 26 32 41
15 16 19 22 26 32 41 53
16 19 22 26 32 41 53 70
19 22 26 32 41 53 70 94
22 26 32 41 53 70 94 127

I read in other thread that manono likes this one more instead MPEG standard matrix.

[Sharc]

Thank you for the matrix.

I think you simply have to try what you like best, or manono may perhaps comment. Often the differences between matrices are subtle and barely visible.

I wonder a little about the DC coefficient of the non-intra matrix being a 12. I thought it should be 8 or 16 to comply with mpeg specs. Not sure, however.

[tom942]

No idea about the DC coefficient, although I have read the thread about how a matrix works.

The SONY matrix is also the one that is included in Matrix editor as 6-Medium-Low(2500-3000). It is curious that it's recommended for that bitrates, and in OPV gives me a high Q.

The movie I'm testing with is Casino Royale with 2 tracks. The average bitrate is 3192.

See you.