RB 1.03 Pro vs DVD2ONE v2 vs ...

[UncasMS]

a new dvd2one version 2 has been released this monday - time for a little comparison


a couple of screenshots taken from the final output created by the very latest versions of:

- DVD2ONE v2
- DVD Rebuilder 1.03 Pro (+ procoder)



1. dvd2one


1. rb



2. dvd2one


2. rb



3. dvd2one


3. rb



4. dvd2one


4. rb



+++++++++

and finally a low-action scene which clearly demonstrate some other aspects apart from the fact that dvd2one's transcoding engine resulted in very blocky frames in high action scenes as shown above:

a) dvd2one darkens the overall picture quite visibly
b) dvd2one smoothes the picture very much and thus provides much less details and structure [c.f. the lights at the bottom]
c) dvd2one produces quite a lot of 'mosquito noise' which can clearly be spotted around the heads for example

5. dvd2one


5. rb

[blutach]

They all look like overgrown mosquitos. No wonder they're noisy.

It is not a very good transcoder is it? The blocks are outrageous. But to put it up against Procoder 2 at mastering quality is like putting up a 3 year old against Pele in his prime.

How do you find these frames?

Regards

[Mig$y]

Nice post UncasMS

Mmmm, Legoland, blockville.

What was the time difference between encoding and transcoding?

Blu - Pele must be almost 80 now!

[UncasMS]

finding frames is always trial & error

loading the vobs into vdmod and then simply scrolling through *the mess* is what i usually do

having found the usual suspects i save them to png and open another instance of vdmod importing the corresponding vobs from another encoder and go to the very same frame


of course you might consider this comparing apples to oranges when using dvd2one v2 and procoder with mastering quality settings which i always use

but on the other hand it's the final output that counts for me and not the routine or the amount of time it takes


talking about times:

dvd2one ~30min
rb 199min

btw dvd2one was used with BEST mode

[apfraats]

Nice post UncasMS

Mmmm, Legoland, blockville.

What was the time difference between encoding and transcoding?

Blu - Pele must be almost 80 now!

This answer is for general purpose, not absolute as time difference is completely depending on implementation such as language level used.
Programming in interpreted Basic will be >1000* times slower then when it's just straight done in machine code assuming good programming practises.

So a transcoder in Basic will be slower than an decoder/encoder in assembly language.

Transcoding = Taking the original MPEG-2 bitstream, leave some things out to change the bitrate, causing significant quality loss at average compression in general but is fast. (why care about time ? With DVD-RB you put 5 DVD's in batch, get drunk and sleep whole day and wake up seeing the results and being in a good mood).


Encoding = Decoding the original MPEG2-stream to a normal picture as the DVD-player does, but this is done with 1 and 0 's so no quality loss except for the faults already present in the original stream. And after decoding it, making a total new Mpge-2 stream out of the decoded frames and even take in account motion and other aspects of the movie, which generally has much better results than transcoding.

But the general mistake is that you can't compare trancoding and encoding because decoding has to be done too using encoding. So in fact, it looks like this:

ORIGINAL MP2 ----> TRANSCODER -----> RESULT MP2

ORIGINAL MP2 --> DECODING --> stream of frames --> Encoding ---> RESULT MP2


Just to simply explain..

Compresssing 80% with transcoding is cutting down on 80% on every part of the stream.

Compressing 80% with decoding/encoding is cutting down the streamSIZE to 80%, but bitrates at high motion scenes can go up to almost (or sometimes even more) then original bitrates, at least when using VBR.

With transcoding almost everytime the high motion scenes become in trouble because there all the original bitrate is needed to reproduce the scene. Decoding/Encoding can do this by 'stealing'' bitrates on parts were there is less need for them, transcoders in general can't....

As it's easier to take the stream leave something out, and store this to disc in one run, it's generally also faster.

Decoding/Encoding is GENERALLY SLOWER because:

Software decoding has to be done first.
Then Encoding has to be done.
There have to be true heavy mathematic calculations for the vectors in the MPEG-stream.
The encoder often is a so called muti-pass proces. It has to go over the same part of streamed frames again 1 to x number of times to better distribute bitrates on the encoded part depending on the charasteristics of the source frame stream.

Transcoders are GENERALLY FASTER because:

It has to go over the stream once, leaving out some vectors to get the required bitrate. So in fact it''s a kind of filtering. Like when you have MP3 at lower bitrates the max. freq will go down, moving down the point to which high frequencies are heard.
So in a simple way, you can look at a trancoder like a filter, leaving out the most non-very-basic material that makes up details for the picture, same as high frequencies in sound. But if the sound only has merely high frequencies (as more motion in movies) the sound is badly reproduced.
While if the sound is only bass (low motion) the sound seems not to be very badly reproduced (although you'll always have high frequencies even in BASS sounds, but they are of very small amount)

So a Bass Sound seems better reproduced than a treble sound, when cutting down on bitrate. The same happens transcoding high motion scenes regarding to low motion scenes. As MPEG-2 is based on motion differences between pictures. So slow motion scenes (bass) tends to look better then high motion scenes (treble) cutting down on bitrate, untill even blockiness appears in still scenes of the movie...

Yes I sure know this isn't the full truth at all, but it's just ment to point things out in a very quick glance.

And by the way, this is for SOFTWARE BASED transcoding and decoding/encoding. For hardware based transcoding decoding/encoding all goes in real time usually. This is done in youre HDD-recorder for example.

So SOFTWARE transcoding will be generally faster, depending on the intelligence of the software used. Just look at schrinks so called Adaptive Error Compensation (AEC), which is a 'trick' to optimize the transcoder for quality, but at the expense of extra time. Even this doesn't prevent blockiness action scenes.

So it's TIME over QAULITY or QUALTY over TIME in general

So if software is written in low level languages and good programming practises are used, a pure transcoder will be faster then any decoder/encoder combination (using VBR, CBR is worthless in this context)

By the way, MP2 has always artifacts and decoding/encoding it again at even the same bitrates (so same size) will decrease quality as result of the lossy compression used.

At some low degree of compression, especially when there is general overhead in the stream, you can even debate at very low reduction levels, what to use best: A very 'good' transcoder or going through decoding/encoding ?

[jeo]

apfraats
i agree with you(in parts) because depend the quality of the engine used inside the transcoder...dvd2one is not dvdshrink.

UncasMS,
the result show that dvd-rb(using procoder) is better.
was used any script with filters? (i don't know if dvd-rb use scripts for procoder)if yes,show us.i'm sure that using CCE could be better!

thanks all
[edited] Pele have 69 but is older than procoder!

[UncasMS]

hmmm, there is an aweful lot of misinformation in your post

this is done with 1 and 0 's so no quality loss except for the faults already present in the original stream.

0 and 1 are the basics of the digital world and transcoders are not working the analog way *g*

on the other hand an encoder, too, of course results in quality loss depending on how much data it has to reduce

Compresssing 80% with transcoding is cutting down on 80% on every part of the stream.

wrong - transcoder do NOT generally reduce the data of each and every frame

when applying some 20% reduction in shrink i and p frames hardly get touched

b-frames, however, are those frames where the compression is being applied and therefore we come across certain frames which look horrible compared to the original or compared to frames produced by an encoder


an mpeg stream consists of GOPs - Groups Of Pictures

I,P and B frames form a gop, which might look something like this.
I-B-B-P-B-B-P-B-B-P-B-B-P-B-B-I-B-B-P-B-B....


I or Intra-frames contain ALL picture information or residual data only
these frames can be reconstructed without reference to other frames

P or Predictive frames contain residual data and MV/motion vectors
the picture will have to be reconstructed with reference to the previous I or P frame

B or Bidirectional-predictive frames again contain residual data + MV
the pictures wil have to be reconstructed with reference to past AND future I or P frames


a TRANSCODER removes some of the residual data by means of a requantization algorithm but leaves MV untouched

ENCODER like CCE, procoder, hc enc or quenc etc encode the entire frame and recalculate motion vectors which takes much more time then compressing only certain data in the frames


thus transcoders work faster but encoders will provide better quality the more compression will have to be applied

[UncasMS]

UncasMS,
the result show that dvd-rb(using procoder) is better.
was used any script with filters? (i don't know if dvd-rb use scripts for procoder)if yes,show us.i'm sure that using CCE could be better!

of course an avisynth *script* is being used in rebuilder (it always is) but i used no filters whatsoever to keep the comparison fair

and NO cce wont do any better than procoder especially not when it comes to lower bitrate scenarios!

[jeo]

of course an avisynth *script* is being used in rebuilder (it always is) but i used no filters whatsoever to keep the comparison fair

i don't knew that could be used scripts(& filters) for procoder and was a smart way no using filters for comparisons.

and NO cce wont do any better than procoder especially not when it comes to lower bitrate scenarios!

right,i knew that CCE is not so good to lower bitrates but had forgot this "detail" when i posted.
( of course i like too much of procoder and was used in dvd2svcd when ....forget about it,long history )

great explanations, and thanks!

[UncasMS]

i don't knew that could be used scripts(& filters)

rebuilder uses avisynth scripts and is therefor able to handle all those lovely & powerful avisynthfilters available

c.f. here: http://forum.digital-digest.com/showthread.php?t=54372

[ElBoricua433]

I was planning to try out the new DVD2One v.2 thing, but since you already tried out and see how it came out, you changed my mind

[jm1647]

@UncasMS - great explanation and experimenting - I learned something again today. Thanks

[apfraats]

hmmm, there is an aweful lot of misinformation in your post



0 and 1 are the basics of the digital world and transcoders are not working the analog way *g*

on the other hand an encoder, too, of course results in quality loss depending on how much data it has to reduce



wrong - transcoder do NOT generally reduce the data of each and every frame

when applying some 20% reduction in shrink i and p frames hardly get touched

b-frames, however, are those frames where the compression is being applied and therefore we come across certain frames which look horrible compared to the original or compared to frames produced by an encoder


an mpeg stream consists of GOPs - Groups Of Pictures

I,P and B frames form a gop, which might look something like this.
I-B-B-P-B-B-P-B-B-P-B-B-P-B-B-I-B-B-P-B-B....


I or Intra-frames contain ALL picture information or residual data only
these frames can be reconstructed without reference to other frames

P or Predictive frames contain residual data and MV/motion vectors
the picture will have to be reconstructed with reference to the previous I or P frame

B or Bidirectional-predictive frames again contain residual data + MV
the pictures wil have to be reconstructed with reference to past AND future I or P frames


a TRANSCODER removes some of the residual data by means of a requantization algorithm but leaves MV untouched

ENCODER like CCE, procoder, hc enc or quenc etc encode the entire frame and recalculate motion vectors which takes much more time then compressing only certain data in the frames


thus transcoders work faster but encoders will provide better quality the more compression will have to be applied

I did the explanation at a somewhat higher abstraction level. Not to confuse anyone too much on this complex material. (Which I just have to read a good book about , because I'm still not able to build a superfast multipass encoder with exceptional quality with average 1.0 kbps bitstream output., what people seem to want, claiming good quality results with an average 2.0 kbps bitrate, which I simply won't believe.... ).

So a frame is the frame we see on TV, here at 25 frames/sec native resolution of 720*576 (PAL). I didn't mean a MPEG2 frame. I mean what we see. At this level of of abstraction we don't talk about the details of a MPEG2 stream. Just know it's a stream with a certain bitrate that's generating the picture seen on TV. So at that level compression ratio is seen in much wider context, such as a clip of 12 seconds of video. Than you can say 80% reduction will be 80% reduction in bitrate for every frame, speaking of a pure transcoder. If you would see a graph such as with bitrate-viewer, you would see a kind alike graph as output of 80% of the original values (bitarteviewer shows bitrate at a certain time in the stream showing it with 1 second time intervals and interpolates the graph to the next second with a straight line.)

Not talking about stuff line I,P,B frames, that complicates things too much at that level of abstraction. We don't care for details, because the story would probably sized 1000 pages or something like that.

Just knowing a bitstream respresents changes from one frame to another as seen on TV is enough, they way it's exactly implementated is another 500 page story.

As seen at that level, we even don't wanna know about GOP's and so on.
It isn't necessary too.

With 1's and 0's I in fact stated out the digital signal processing. What's a computer doing besides playing with 1's and 0's ? In fact that's all we need to know to make clear there are no losses due to analogue signal processing and converting. That I was saying because I used the comparision to a DVD player connected to a TV which most of the time is done analogue (in my environment at least). So we won't lose quality here because of this proces done in the 'digital world'. However as MPPEG is a lossy compression format, the decoding/encoding step will always lose quality because it's lossy saying you loose some information in this way.
If you did decoding/encoding/decoding/encoding even without any compression quality is lost. So you'll never have the 'perfect' reproduction because it's digital....... Yep it's digital but everytime with encoding you loose some 'digital' info, so quality will decrease every time you do a new decode/encode step, till finally no quality is left at all.

This to clearify that always there is a loss in quality if you do decoding/encoding, even digitally.

I also stated that at very low compression one might to consider the use of a 'good' transcoder over the decoding/encoding proces.

Also I stated that using decoding/encoding from MPEG2 to MPEG2 much better results can achieved as this is a complex mathematical proces based on the original picture stream in frames and the differences between them.

So in fact we tell the same story, using different levels of abstraction.......

We could even discuss the encoding matrices to be used, how they work, what they do, and why we need to know about them and when to use which matrix.....
But I won't think it will help to state the difference between decoding/encoding which is often reffered to by using the word encoding alone, and transcoding.

So let's say: just for 'knowledge transfer' purposes.

[UncasMS]

let's agree on this:

somewhere in your essay a couple of 0's and 1's seem to have gotten lost due to different signal processing


but thanks for putting things straigth - i'll give it some rest now

[elizerrojas]

let me first say that RB-pro and HC which how i use it, are probably the cheapest combo with the best quality. i use them from time to time. but let me tell you why i'll continue using dvd2one v152 and now dvd2one v2 for most of my backups.
because:
1)it takes RB/HC from 4 to 5 hours to encode a movie, i don't want my compruter working that much and that hard,
2)i use dvd2one in main movie-only mode which gives me a great quality( dvd2one gives much more compresion to extras and other stuff and very little to the main movie) and it only takes from 20 to 30 minutes.
3)from what see in the RB vs dvd2one screenshots, the quality is not that different to overlook my first reason.
before anyone says that they are not willing to give up quality for speed, let me just say that, dvd2one v2/ main movie only produces great quality backups, if you want proof of it, just take a look at the screenshots post it here.
p:s: i have a few backups done with RB-pro/HC, they are indeed better than those made with dvd2one, but the difference does not merrit having to wait from 3-5 hours for a backup.
just my 2 cents.