DVD Shrink - which MPEG-2 encoder does it use?

[clokkevi]

I came across an .iso image, and when I burned it,
DvdInfoPro showed me that DVD Shrink was used to make the .iso file.Implementation id = DVD ShrinkI also checked the VIDEO_TS\*.vob files with a hex editor,
and VTS_01_0.VOB (5.13 MB) contained, at offset 0x087E the string@(#)Apple MPEG-2 Encoder v212-20030723 [7000000 900 R8000000 w2 e2 E2 s0x0 V0x0]while VTS_02_1.VOB (0.99 GB) contained, at offset 0x087E, the string@(#)Apple MPEG-2 Encoder v212-20030723 [6900000 19561 R9000000 w1 e2s E2 s0x20000 V0x0]
I'm hoping that the original DVD was < 4.7 GB so that DVD Shrink did not need
to re-encode the MPEG-2 files, and I'm wondering if those
Apple MPEG-2 Encoder v212-20030723 tags could be the evidence I'm looking for..!
Does anyone know what encoder DVD Shrink uses to re-encode MPEG-2 to a smaller size?

(Or could anyone confirm that it does not use the Apple MPEG-2 Encoder..?

[NaN]

Hey cmon! Shrink doesn't *encode*, it transcodes. Means it changes the quantization of the frames only.

Man, there's no that unbelievably fast encoder! Did you never really reencode a DVD? That takes hours!

Sure the original mpeg2-header stays intact, why should Shrink change these values?

And humbly I might say, if the iso is perfectly 4.36GBs big, it was shrinked.

Cheers, NaN

[clokkevi]

Thank you very much for your reply, NaN! :)
And humbly I might say, if the iso is perfectly 4.36GBs big, it was shrinked.Aha..! No, the iso image is only ca. 2 GB, so I guess that means DVD Shrink did not shrink it!:D
(This isn't a feature movie, it's a software tutorial video.)
Shrink doesn't *encode*, it transcodes.
Did you never really reencode a DVD? That takes hours!Hehe - while I've experienced lengthy MPEG-2 encoding - I've never used DVD Shrink!
Means it changes the quantization of the frames only.I did try to read about quantization in JPEG, and I think I maybe understand some parts of it:
Is it true that
- the reason for DVD Shrink's speed is that in an MPEG file,
the DCT - which is the lengthy process,
(since it involves a lot of cosines, and some sqrt calculations)
- is already done.
DVD Shrink only needs to do a re-quantization (simple divisons, very quick),
using higher values in the lower-right corner of the quantization matrix,
then the high-frequency signals (sharp features in the image) will be reduced a bit more,
making a smaller file.

[mpucoder]

A little OT, but DCT uses no sqrt. And a proper coding uses no cosines either, as there are only 64 possible values that can be pre-computed and retrieved from tables.

[NaN]

@clokkevi: additionally Shrink need not to do the calculation of the motion vectors, another cpu intensive job. BTW: you're welcome.

@mpucoder: thanks for giving us a little insight!

Cheers, NaN