Incredible quality - The Departed with CCE OPV

[nashcity]

Just thought I would throw this out there in case there are people who are currently attempting to backup "The Departed". It is a very long movie, approx 2.5 hours, and I attempted 2 different methods to try and gain the best quality I could. Of course, this wouldn't have been possible without the AMAZING program Jdobbs has provided for us - this post is really all about how his program allows someone like me, who isn't the most educated when it comes to this stuff, to be able to backup a DVD with incredible results.

I use CCE and tried both the multipass (4-pass) and OPV methods and I've got to say, the OPV method was substantially better. I ended up with a Q-value of 10! Compression was 64%! For those who know what that means, it isn't surprising that my backup looked almost identical to the original when viewed on both a 32" CRT and a 42" LCD. I was amazed. It also took 1/4 of the time the 4-pass encode did. This isn't the first time this has happened, I regularly use OPV when I can get a Q-value of 25 or less because I feel that more often than not it results in better picture quality with less noise. For those who haven't tried it, I would give it a shot - you may never go back to multipass.

Thank you Jdobbs for making me look like a pro.

[kumi]

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)

[linx05]

Wow kumi. That looks amazing. I've still yet to get into the whole matrix thing. I might start now.

Good to see you used .png for the screenies ;)

[writersblock29]

@Nashcity
You can very often get some amazing stuff out of OVP encodes, to be certain. I have run into a few projects, though, that I just couldn't get quite to my liking using OVP--but a 2-pass run HC made me smile and commit it to disk. Miami Vice, for example--with the grainy, hand-held camerawork--just didn't look as good to my (admittedly aging) eyes using OVP as a multi-pass did. A test of Braveheart yeilded the same thing to me. Funny thing, though: Munich looked radically different in favor of OVP. I think it's all in how the encoder interperets your project and the project itself. You're right, though: in most cases, OVP encodes give you very satisfactory results while keeping you from spending your younger years watching an encoder's progress bar. Even viewing the result on a 50" HDTV.

[Voodoochild]

I red the post and have to say, I was impressed with what people says here about OPV performance. So searching the forum and Google for some more knowledge on OPV, I backed up "miller crossing" which required 93% compression with OPV. Selected q value by DVDRB was 4, got final size of 4.20GB. Looking on same scene of part of the movie both on the original and DVDRB ISO file saw no differences, taking 10 images with MPC and compare them, did not show any differences as well. Total backup time was 01:10 hour.

Question is, is it correct to assume that in low compression movies like "miller crossing", there will be almost no difference between Original and the Backed up copy?? By that saving allot of process time...If yes from which point (q value) does it better to use the traditional 2, 3 pass encoding?

Another question, I've noticed that though I chose AVAMAT6 Matrix, DVDRB used the default medium_medium Matrix, Does that mean I can't use custom Matrix with OPV?


10x Elad.

[archaeo]

Another question, I've noticed that though I chose AVAMAT6 Matrix, DVDRB used the default medium_medium Matrix, Does that mean I can't use custom Matrix with OPV?


10x Elad.



That is correct. in OPV, CCE uses its standard encoder matrix only. Only in multipass can you select a custom matrix. I'm not sure if you can get around that using RB-Opt, however...

[writersblock29]

@Voodoochild

It really does depend on the sensitivity of your eyes and the quality of your viewing equipment as to when to use either OVP or multipass. If you have a low Q (this is subjective, but I usually aim for less than 25), you normally have a tough time figuring out which is your original and which is your copy. The lower the Q, the higher you'll score; a Q value of 4 is doing quite well, indeed.

Often times, running a prepare pass using OVP settings will give you a good estimate of how good of quality you're in for if you were to allow your project to finish--so if you run a prepare and wind up with a Q of, say, 40... you might do well to figure out what stuff you can live without before investing time on encoding.

There are tradeoffs (isn't that true of everything?), however. With OVP, you'll wind up with a given quality at the expense of accurately reaching a given target size. If you're only archiving DVDs to a hard drive and trying to save space while doing it, this isn't a big deal... but it can be annoying to be aiming a project for a DVD-R when it finishes encoding at 4.40GB instead of 4.36. That's the downfall. The upside is that you'll have a pretty good idea how well it'll all look before ever commiting to encoding it, and of course it takes less time to encode 1 pass than it does the traditional multipass approach.

By the way, at 93% encoding, many people would shrug, open DVD Shrink, and transcode it. This is source-dependant, of course, but the main attraction of OVP seems to be the time saved in processing a disk while maintaining high quality.

[Voodoochild]

I guess I will have to practice with it more to see in which cases it better for me considering the equipment I have to use OPV or multi pass encoding.
I do not use DVD Shrink any more since DVDRB build the whole DVD in better way then DVD Shrink, I found out that
A. using DVDRB will produce DVD that can be played on more DVD players

B. more important I discovered, Even wrote a post about it while ago, that in some movies even though compression is low, DVD shrink gave me unclean movies with transition between scenes that weren't smooth (fragile of a second of pixilation between some scenes).

10x allot,

Elad.

[setarip_old]

@Voodoochild

Hi!A. using DVDRB will produce DVD that can be played on more DVD playersI don't believe there is any data to support this - as DVD Shrink creates a 100% DVD-compliant "package".

You may have obtained varying results due to different burning methodology (DVD Shrink does not, in and of itself, burn), different media, different burn speeds, etc.

[Voodoochild]

I want get into differences between DVDRB and DVD Shrink here, each one has his own experience with the software, I know I never had a DVDRB backup that didn't play well, stopped jumped etc' in some parts and that good enough for me.
The subject of this thread is OPV, So I discuss that only on this thread.

10x

Elad

[Blue_MiSfit]

I'm shocked. A 50% reduction using MPEG-2 with such little loss (at least in those screenshots) is freaking amazing. Seriously.

If only broadcasters had a clue... then the paltry bitrates on Satellite / Cable would be enough!!!

~MiSfit

[manolito]

That is correct. in OPV, CCE uses its standard encoder matrix only. Only in multipass can you select a custom matrix. I'm not sure if you can get around that using RB-Opt, however...
Yes, with RB-Opt you can use OPV with a custom matrix. I remember Jdobbs saying in earlier post that he did not implement it because he could only get an acceptable prediction accuracy using the standard matrix. But so far I have been getting pretty good results with OPV using a low bitrate matrix like AutoQ2 (aka AVAMAT 6).

Cheers
manolito

[deity67]

What is the opv method?

[writersblock29]

@deity67

The OVP method's kind of mutated over the years, but its roots are the same today. Hopefully I won't confuse the both of us, but I'll try a shot at explaining.

When you do a traditional multipass encoding, you're not really all that sure what level of quality you're going to wind up with; in fact, many multipassers know well the experience of canceling an encode well before it finishes up just so that they can check out what they've done so far, and judge for themselves if it's worth investing several more hours encoding for the quality they'll wind up with (since Rebuilder encodes a project in segments, it's possible to allow a segment to finish encoding, then abort the project so that you can watch that segment). This is because the encoder's locked in: It's given a specific target size to meet (the bitrate's been specified, as have all other encoder settings), and it becomes more concerned with meeting that target size than it is in achieving a given quality. That, in fact, is why you'd run additional passes--so that the encoder can attempt to maximize the quality for the size restrictions it's given. Each pass allows the encoder to redistribute bits to areas that need them most. Trouble is, more passes equate to more time spend running a given project. If you're running an encode at real-time, then a two hour movie will take six hours to finish at three passes.

In comparison, an OVP encode (OVP stands for One Pass Variable) takes a chunk of that video, mathmatically reduces its target size goal (it looks at what size the original material is, and subtracts from that the percentage it needs to be reduced), then attempts to find the highest quality setting it can while sorta-kinda keeping the filesize within goal. Accuracy is frustratingly impossible (although sometimes you can get pretty darned close) due to the fact that only a small percentage of material is looked at during analysis. After the analysis, the highest quality possible is reported to the user via what's known as a Q factor, and will tell the user exactly what to expect, quality-wise, from the finished encode. The lower the number reported, the better. For example, a reported Q factor of 1 is the creme da la creme--it's the best quality the encoder could possibly give regardless of file size. Most projects will clock in at right around 20-30, which still isn't all that bad for most users. My own personal taste dictates that anything over 30 is going to allow me to see differences between my source and my copy, and tells me way before committing to encoding the full project whether it's worth running in the first place... or whether I need to tweak things a bit (removing extras, unneeded audio, running filters, ect). So there are advantages to this approach:

1) Unlike Forrest Gump with his box of chocolates analogy, you DO know what you're going to get in terms of quality well before tying up your machine with encoding.
2) Many times, the quality of an OVP encode will look just as good as the quality of a multipass, simply because the encoder isn't as focused on maintaining a given filesize--it's focused on maxing out the quality with the space given. So while running multiple passes is aimed at improving the distribution of the bitrate, this has already been roughly factored during the first analysis pass of OVP.
3) Since only one encoding pass is used after doing the analysis, encoding a project takes far less time. At real-time, a two-hour movie takes two hours to encode, not six (in the example of using three passes). Since most processors these days are on the beefy side, in reality you can expect better than that if your system's on the young side. Dual-core processors help a ton if you're using HC, since you can run multiple instances of the encoder and have two segments encoding at the same time. On my system, a two-hour OVP can take roughly a half an hour to finish encoding. Think of it as getting DVD Shrink speed with CCE quality.

But there's a pricetag to this payoff. While Jdobbs has been awesome at getting the final filesize down to under the size of a recordable disk, the very nature of OVP dictates that there will be times that you wind up with a project slightly oversized (this is especially true if you've tweaked the target sectors in the INI file of Rebuilder--and part of the reason Jdobbs recommends against doing this). In such a case, you're faced with either running that project through DVD Shrink or other transcoder (isn't part of the point of re-encoding so that you wind up with higher quality than transcoding?), or having to run the project again with different settings (thus destroying the "time saved" advantage). Granted, you'll often get higher quality by running a transcoder on an oversized OVP project than you'd have gotten if you ran the transcoder off the original material... but again, it defeats the purpose, and the time spent running a transcoder--once factored in to the total time you've spent on a project--can defeat the time-saved issue. Because oversizing happens very rarely, OVP is still a good option if you have multiple projects and don't want to tie up your machine for days doing them.

[manolito]

OPV stands for "One Pass VBR". It is not the same as the one pass VBR which is implemented in QuEnc, though. In QuEnc you can specify an "Average Bitrate", and QuEnc will do its best to reach this desired bitrate even with only one pass.

In CCE the OPV method is basically a "Constant Quantizer" method with the exception that the quantizer will change when the maximum or minimum bitrate is reached. This means that you cannot specify an average bitrate, you have to specify a "Q" value which probably stands for quality. The lower the better, but usually a Q value below 30 gives very good results.

Because you cannot use an average bitrate with CCE's QPV method, it is necessary to run a couple of "Prediction" encodes with only a small percentage (usually between 1% and 2%) in order to find the Q value which will give you the desired bitrate.

Cheers
manolito

[joesmart]

Slightly off-topic, but thanks to writersblock29 and manolito for their explanation of OPV--up until reading that, I had no idea what it was. How does one go about setting up an OPV encode? Thanks again.

[writersblock29]

@joesmart

No problem! Settup depends on the encoder you wish to try.

HC (run the DVD Rebuilder full installer, and it'll automatically install the most recent HC release):
First off, make sure you've got HC encoder installed and the proper path set in Rebuilder's setup option. Then, from DVD Rebuilder's main screen, go to "Mode/Encoder/HC Mode." Once done, Go to "Settings/HC Settings/Quality Speed Selection/Best" (for the highest quality HC can offer). Then go to "Settings/HC Settings/One Pass CQ VBR." The rest of your setup depends on what kind of processor you're using. If you have a dual-core, then you can head to "Settings/Multiple Encoder Processes," and make sure that's checked. This will run more than one instance of HC, utilizing both processor cores and speeding things up tremendously. From there, you can either one-click it and just see how it all goes, or you can run just a prepare stage and see what Q value it gives. HC's Q values appear to be different than CCE's (unless I'm wrong--but the readings are never the same between the two for me), but the idea's the same--the lower the value, the better the quality.

CCE SP
Make sure CCE's installed and that Rebuilder has the proper path set up for accessing it. From there, Go to Rebuilder's main screen and select "Mode/Encoder/CCE Mode." Then go to "Settings/CCE Settings/" and make sure whatever version you're using is checked. You'll also see the option under "Settings/CCE Settings" for "One Pass VBR (w/analysis)." If this is greyed out, you're probably using a Basic version of CCE, and your best bet is to use HC for this. To my knowledge, CCE Basic sticks you to using only 2-pass settings... unless something's changed. If it's checkable, you're on your way!

Using either method, just proceed as you normally would. Rebuilder will automatically do the AVS creation and information gathering, followed by sampling your video and running an analysis pass. Encoding, if using the one-click option, will immediately follow and be done in a jiffy. There may be other options for other encoders, but CCE SP and HC encoder are the only ones I'm immediately familiar with.

Hope this helps!

[joesmart]

writersblock29--thank you. am eager to try this out. :thanks:

[Sharc]

@deity67

...... and tells me way before committing to encoding the full project whether it's worth running in the first place... or whether I need to tweak things a bit (removing extras, unneeded audio, running filters, ect).

If I understand correctly: Tweaking things (changing bitrate, blanking of extras etc.) by means of the RB Viewer/Editor after the Prepare phase is pointless for OPV because it won't change the final Q value for the subsequent encoding. Means the tweaking must be done before the prepare, eg. by means of Vobblanker. Is this correct?

[jdobbs]

That's correct. The prediction has already been completed -- so the Q won't change. In fact the only way to do that would be to reaccomplish the prediction run every time you save from the editor.

I'll see how hard that would be to do.

[Sharc]

:thanks:

[FilipeAmadeuO]

Jdobbs
I usualy do OPV encoding and only if Q>30 i go for multipass.
Is it possible to include in the editor the possibility to change the Q factor after the prepare phase ?
Because sometimes the Q valor is not as exact as i would expect so i like to tweak a little to try to get to 4.37Gb.

[Voodoochild]

Hi

Just did "CRASH" from 2004.
After removing all extra material got 74% compression with avg bitrate of approx' 5000. For testing I did to projects.
1. CCEAQM=1, 3 pass, avamat6 as base matrix (aqm will change it, I know).

2. CCE 1 pass VBR, Q = 11.

project 1 (AQM) turned to be 4.35GB,
project 2. (1 pass VBR) turned to be 4.30GB, not bad at all
Looked at the results carefully, took 8 images sample and also looked on same scene in both projects, couldn't tell the difference. That was 74% compression reminding you...

I definitely think anything below Q=15 is great quality and allot faster!!

10xs

Elad

[Bh4i]

Everytime i read something about OPV, i hear this 'Q-value'.

What is a 'Q-value' and what does it mean? Google wont help either... And whats the connection with OPV?

[jdobbs]

In CCE Q-Value stands for "Quality"... and it represents a mixture of several things -- including quantization. Generally in other encoders it outright means quantization. The term OPV usually means you are talking about CCE (One Pass VBR).

In HC and QuEnc the equivalent to OPV is something called CQ (constant quantizer) mode. It means you have selected a fixed quantizer so that each picture gives the same level of quality. But -- since it concentrates on keep each picture at a constant quality level, it doesn't care whether the total of the pictures is big or small. That's why you have to do prediction runs.

There is one more type of one pass VBR encoding. It is used in QuEnc (and a lot of real time encoders like those used on a standalone recordable DVD unit). It uses VBR, but has a limited window that is used for bitrate distribution. It typically has lower quality levels than two pass or CQ/OPV.

[Sharc]

I did 2 discs with CCE 3-pass and CCE OPV.

For OPV the Q factor was 29 and 36 respectively (!). Reduction was 70% and 64% respectively for the 2 discs.

I used the same matrix (CCE default) all the time in order to compare apples with apples.
I compared a couple of frames that I extracted by means of DGIndex, and enlarged these significantly in order to better visualize any differences.

Result:
- Both OPV and 3-pass hit the target sectors very well (I don't discuss the last few MBytes difference).
- There were subtle differences when comparing the enlarged frames 1:1, but it was almost impossible to tell which frame is better.
- Some areas within the same frame looked slightly sharper or smoother for OPV or 3-pass, and vice versa. Some frames looked perhaps slightly better for 3-pass than for OPV, and vice versa.
- Almost no difference regarding (slight) macroblocking in certain scenes: OPV and 3-pass macroblocks visible at the same coordinates within a frame.

After all:
Impossible to me to give clear preference to OPV or to Multipass, even at Q as high as 36 for OPV in my test cases
(CCE btw. reported during encoding a Quality scaling for I/B/P of typically 5/5/7.5, respectively).
Even when watching the movie, it was impossible to give preference to OPC or Multipass.

My conclusion:
If OPV would support the same flexibility for bitrate re-allocation after the Prepare by means of the RB editor as it does for multipass now, I doubt if I would revert to multipass..... But perhaps I was just lucky with the selection of the particular discs?

[manolito]

There is one more type of one pass VBR encoding. It is used in QuEnc (and a lot of real time encoders like those used on a standalone recordable DVD unit). It uses VBR, but has a limited window that is used for bitrate distribution. It typically has lower quality levels than two pass or CQ/OPV.

What do you mean exactly by "limited window"? Some time ago I did ask Nic how QuEnc's one pass VBR works, but I did not get a clear answer. Do you suggest that the bitrate excursion is somehow limited? And if so, would this necessarily be a bad thing? In CCE and HC there are "Bias" settings which also limit the bitrate fluctuation, and from what I have read so far, this is desirable in most cases.

Anyway, QuEnc's one pass VBR mode does deliver a very high quality for my eyes, and it also does a very good job reaching the desired size while staying DVD compliant at the same time. This is certainly not true for QuEnc's CQ mode. This mode does not care for the specified max bitrate. Using CQ mode in QuEnc will most likely result in an encode with bitrate spikes well above the DVD specs.

For HC it is a different story. Hank did implement a modified CQ mode which he calls "CQ_MAXBITRATE". In this mode the max bitrate is observed. This mode is therefore very similar to the CCE OPV mode (the difference is that in HC there is no min bitrate setting).

Cheers
manolito

[Sharc]

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.

[kumi]

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

[jdobbs]

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?

[Sharc]

Jdobbs
Is it possible to include in the editor the possibility to change the Q factor after the prepare phase ?


You may want to tweak the Q by means of RB-Opt after the PREPARE:
http://forum.doom9.org/showthread.php?s=&threadid=75202
Good luck!

[lilhobo]

what is this CCE matrix people are talking about??? how do i use it and where is the setting in rebuilder??

PS. how many test run does Rebuilder do???, with the time taken woudlnt it be easier to do multipass??

PPS. why does it do Q=78, 226, 276??? dont u want it under 30??

[jdobbs]

It might be easier, but it wouldn't be faster to do multipass. The prediction passes only encode 1-2% of the stream in order get a feel for the Q Value required. The number of "test runs" depends on the output size. DVD-RB predicts what the size should be in order to make a 4.32GB DVD... if it comes out smaller or larger, it does another run with a new Q value that is created based upon the sizing curve. Most of the time it takes 4 or fewer prediction passes for CCE... but it can be more depending upon the source.

[jdobbs]

why does it do Q=78, 226, 276??? dont u want it under 30?? It does whatever it takes to make it fit. If you set it to 30 and it came out to be 7GB you wouldn't have accomplished anything.

[lilhobo]

well the original was 6Gb disc
"- VTS_02: 3,259,138 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 343,894 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 51.8%
- Overall Bitrate : 1,582/1,266Kbs
- Space for Video : 2,216,400KB
- Analyzing VTS_02 for optimal Q factor.
-- TargetSize (sectors):1,124,823
-- Sampling 6885 of 343894 frames.
-- Predicted size (sectors) at Q=78: 2,420,855
-- Predicted size (sectors) at Q=226: 1,189,120
-- Predicted size (sectors) at Q=276: 1,066,307
-- Predicted size (sectors) at Q=251: 1,119,931
- Q Value selected: 251
- HIGH/LOW/TYPICAL Bitrates: 1,267/1,265/1,266 Kbs"


do i accept that??


PS. BTW, how do i use Rebuuilder CCE and sound encoder?? te LPCM 2 ch is taking up 2 Gb disc space

[jdobbs]

The LPCM is the problem... but, yes, if you want it to fit you have to accept those numbers -- I can guarantee, though, that it won't look very good.

Is there no AC3 track you could choose to keep instead of the LPCM?

[lilhobo]

so how i can i use Rebuilder, CCE and vegas to get that AC3 track???

[jdobbs]

Most of the time there is one already. You would just use "Audio Track Remapping" to make it the default -- and then remove LPCM.

[lilhobo]

hmmm, i extracted the LPCM file and its only 560Mb

Oh i lied....it was only 1 chapter !!! so i need to reencode to AC3 with bewsweet and learn to reaauthorise a dvd LOL

[Fedorov]

Hi all - figured about time I post on here having been a Pro user for a long time now! :)

Thanks for the info in this thread everyone.

I normally use 3 pass CCE for everything but figured I'd give HC a go after reading everything here, I installed the latest .020 version, setup DVDRB to do Multiple Encoders and I tried my SawIII retail DVD...

...hours later (at least 2 hours) I aborted it at around 70-80 percent complete - I can't understand how it can take so long as I expected it to be so much faster than my 3 pass CCE method - there were 2 HCencoder processes running at all times on my Athlon 64 X2 Dual Core 4800+ processor 2Gb memory etc.....

Went back to my normal 3 pass CCE and got my conversion done in 146mins :)

I can't figure anything obvious that I've missed here, I guess I just expected to see a much faster conversion but didn't!!! :)

Regards,

Fedorov.

[lilhobo]

[03:05:26] Phase I, PREPARATION started.
- "One Pass VBR (w/analysis)" mode is enabled.
- Source: NEW FOLDER
- VTS_02: 2,298,799 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 343,894 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 96.7%
- Overall Bitrate : 2,953/2,363Kbs
- Space for Video : 4,136,894KB
- Analyzing VTS_02 for optimal Q factor.
-- TargetSize (sectors):2,099,474
-- Sampling 6885 of 343894 frames.
-- Predicted size (sectors) at Q=42: 3,582,862
-- Predicted size (sectors) at Q=84: 2,406,239
-- Predicted size (sectors) at Q=104: 2,055,632
-- Predicted size (sectors) at Q=99: 2,133,438
-- Predicted size (sectors) at Q=101: 2,101,613
- Q Value selected: 101
- HIGH/LOW/TYPICAL Bitrates: 2,364/2,362/2,363 Kbs
[03:38:00] Phase I, PREPARATION completed in 33 minutes.
[03:38:19] 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_02 segment 3
- Creating M2V for VTS_02 segment 4
- Creating M2V for VTS_02 segment 5
- Creating M2V for VTS_02 segment 6
- Creating M2V for VTS_02 segment 7


Ok guys tell me what you see here in terms of the OPV technique and the (quality ) of the source??

Its giving me 101 at 96% !!!!

Also i remuxed the LPCM to AC3 and got 2 LESS VOBs.....why is it listed with 7 segments still???

[jolson]

What funny DVD is that without any AC3 track?

[setarip_old]

@jolson

It's likely a musical performance...

[lilhobo]

@jolson

It's likely a musical performance...

yeah you are correct, its an musical


.....there s a problem i reencoded 2-ch LPCM to 2-ch ac3 but it doesnt sound correct !!! i use softencode but it seems to have an empty track that very noisy

[setarip_old]

Audiophiles would think it sacrilegious to "down convert" a music video's soundtrack from LPCM to .AC3 - and would sooner sacrifice the video quality!

[jdobbs]

But then audiophiles would have to live with being very disappointed in the video quality. You can't take up over 2GB of the available 4.32GB for audio and get any kind of decent video output.

I'd also point out that listening tests have shown that no one can really tell the difference between the two (LPCM and AC3) when the AC3 bitrate is about 192Kbs or higher (on a stereo source). So it's all in the head anyway. If you really want to be careful -- you can encode at 224Kbs or even 300Kbs and still have lots of space left for the video.

[jolson]

...and *numerous* listening tests (including those I have done myself) shows it to be very easy to differentiate when the source is good and you have a high-quality system that is calibrated. Between AC3 and PCM. Between 320kbps MP3 and CD-Audio. Between CD-Audio and DVD-Audio.

If it's a good musical, put it on a DL disc or two single-layer discs.

[jdobbs]

Double blind tests?

Everyone says they can tell the difference when they know which is PCM -- but nobody can distinguish them when they don't know which is which. It's all psychological. I've heard the same arguments about PCM and analog. The analog enthusiasts are convinced that they can detect PCM and it distorts the "true" audio -- except, of course, in a double blind test, where again they can't distinguish which is PCM.

[AGKnotUser]

Warning! Just ran into a problem when trying OPV with CCE SP and Eragon R1. When CCE SP hits segment 9 it gets about halfway through then just drops out without finishing or giving an error message. Then I tried CCE SP2 and at least it stopped and gave an overly technical error message (see attachment). Tried using a different DVD ripper and the same thing happened. Watch out for CCE SP. no hint of a problem just ignored the rest of the segment and went on to the next one. If I wasn't there to see it I would have lost part of the film.

[Fishman0919]

Warning! Just ran into a problem when trying OPV with CCE SP and Eragon R1. When CCE SP hits segment 9 it gets about halfway through then just drops out without finishing or giving an error message. Then I tried CCE SP2 and at least it stopped and gave an overly technical error message (see attachment). Tried using a different DVD ripper and the same thing happened. Watch out for CCE SP. no hint of a problem just ignored the rest of the segment and went on to the next one. If I wasn't there to see it I would have lost part of the film.

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

[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.