Shrink VS DVD-RB

[Chewy]

I have been splitting dvd's with shrink for a couple of years and can't tell any difference between the originals and the backups. Even my test with kingkong at 54% compression was barely noticable, however I might as well have used dvdrb since it took as long. Above 80% shrink wins hands down
because of speed, from 60-80% then a full encoder is the way to go. Below
60% then shrink is better splitting the title.

[BR7]

@Blu
I couldn't agree more

[techreactor]

I have been splitting dvd's with shrink for a couple of years and can't tell any difference between the originals and the backups. Even my test with kingkong at 54% compression was barely noticable, however I might as well have used dvdrb since it took as long. Above 80% shrink wins hands down
because of speed, from 60-80% then a full encoder is the way to go. Below
60% then shrink is better splitting the title.

I agree with you Chewy, but cannot disagree with Blu too, since for bigger screens and projectors a transcoded DVD will show some quality concerns!!!. But I think with CRT's you just cant make out the difference. I follow the same cutoff %ages as you do but with an exception. below 80% HCenc, Near 60% I use AutoQmatenc with Qmatop and near 50% procoder, and below that I split.

[jdobbs]

What many of the transcoder users find is that when you are connected to a video unit with composite or S-Video connectors, the distortion created by the connection (or a low-end monitor) masks the problems... but if you go HDMI or component (which everyone eventually will) you will definitely see the difference.

But -- to each his own. Personally I do all my backups with encoders -- and that includes the ones I did before I wrote DVD-RB. That's because I know how transcoders work -- and it's just not a good way to try and get quality out of an MPEG stream, no matter what percentage you reduce it.

[ffreezinmn]

it's just not a good way to try and get quality out of an MPEG stream, no matter what percentage you reduce it.

This is very interesting. I have not used DVDRB for low compression yet. I have always assumed (prehaps incorrectly)that a high biterate and low compression would result in a excellent backup using DVDShrink.

With low compression (<10%) will DVDRB complete the job in significantly less time?

Thank you

[jdobbs]

No. It takes the same amount of time no matter how much reduction it has to do. The amount of time it will take is determined by the total number of frames that need to be encoded, the speed of the encoder, and power of the processor.

On an AMD XP 3200+ (older technology) and CCE Basic a typical full backup takes about 2-2.5 hours with DVD-RB.

On an AMD X2 3800 (newer technology) and CCE Basic it only takes about an hour or so..

[Chewy]

jdobbs,
would you clarify "full backup" and "typical" with some quantitative figures in run time and size. assuming "ballpark" guesstimates, please?

tia chewy

[blutach]

@techreactor - the %s are largely meaningless. You need to take into account quant, bitrate and how much "action" there is in the flick.

@chewy - just work on fps. I have an X2 3800 OCed 25% and encode roughly at 30 PAL fps.

Regards

[shrink0]

Hey guy's, IMO I can definitely tell the diff. on a 50" plasma screen, when I use DVDRB,as opposed to shrink,or R4ME, or DVDD.. DVDRB for quality wins for me, that is. I don't use anything else ,unless it fails ,and it hasn't let me down yet... I do use other progs. for quick backups, and they're great,especially R4ME... or shrink to re-author.

[blutach]

or R4ME, or DVDD

These programs do nothing to encode/transcode - they are rippers.

Regards

[techreactor]

@techreactor - the %s are largely meaningless. You need to take into account quant, bitrate and how much "action" there is in the flick.

Agree, I was just giving my method of compressing, although I do look at the bitrates given by DVD-RB before deciding on an encoder/transcoder, but most of the time(95%) the table holds good for a generic decision on the encodes for me.

[shrink0]

These programs do nothing to encode/transcode - they are rippers.

Regards

Yes, blu I know, I should have left out R4ME and DVDD, in my post, I'll have to keep alert next time ok!....
And I'd rather use an encoder like HC in DVDRB ,as opposed to a transcoder like shrink anyday!!!!
regards back to ya!!!!

[techreactor]

I wont even use Shrink for that anymore For low compression I like to use QuEnc with Trellis Quantization enabled

Comments from dragongodz(author)@doom9..........
 
its been said over and over and over again, trellis is 
completely not optimised and a great speed killer for 
a very small(if at all) benefit.

i am very tempted to just remove it since people use it 
and then wonder why it takes so long.

@BR7....Just thought you would want to know.

[BR7]

That would be a shame IMHO trellis puts out a nice quality movie .If he does remove it I will keep the version that supports it.It's a shame people piss and moan so much about speed that's the price you pay for good quality, to me that takes a lot of balls to gripe about a free encoder. If they think they can make a better and faster encoder then have at if not then STFU.That's what I would say if I was dragongodz

[techreactor]

It was in reaction to these timelines.

My system is a amd am2 4200+ x2 with 1 gig of ram. It was interlaced so I didn't even bother using CCE for this. [IMG]http://forum.doom9.org/images/smilies/smile.gif[/IMG]. For HC I used the best profile with the default matrix. As for Quenc I used high quality, 2pass with VBR, and trellis quantization. Obviously since I have 2 cores I had multiple processors enabled.

Overall Bitrate : 2,961/2,369Kbs
HC encoding time Phase II ENCODING completed in 161 minutes.
QuEnc encoding time Phase II ENCODING completed in 1264 
minutes.

Frankly speaking seeing the timelines, I wouldnt even bother to think about using trellis, no matter what best quality it can produce.