DVDRB Pro v0.93.1 Beta - Clarify iDCT choices please?

[samuelal]

Hello everyone!

The new DVD-Rebuilder Professional v0.93.1 Beta has a new iDCT selection list.

When navigating through the main program's menu:
Options -> AVS Options -> Advanced (Expert) options -> Set Decoder iDCT

You get the following options:
Decoder Default
32 Bit MMX
32 Bit SSE/MMX
64 Bit Floating Point
64 Bit IEEE-1180 Reference
32 Bit SSE2//MMX
32 Bit SSEMMX iDCT (Skal)
32 Bit Simple MMX (XVID)
--------------------------
I would be greatful if the savvy ones amongst you (or Mr. jdobbs himself) could elaborate more on the meaning of each of the options regarding 3 categories:
1. Supposed output quality.
2. Supposed output speed rated from 1-8 (in accordance to the number of Decoder selection).
3. User processor type: will an iDCT 64 Bit selection (Floating or IEEE) benefit speed-wise from the use of a 64 Bit CPU under a 32 Bit or 64 Bit OS or does it concern the depth-of-search/quality that the Decoder does quality-wise.

A nice, complete answer would be extremely appreciated.

Samuel.

[wmansir]

I'm going to bump this because I think some kind of forum glitch kept it from being seen since it was posted.

I don't know enough about the particulars to elaborate fully on every option.

[Fishman0919]

Originally posted by samuelal
I would be greatful if the savvy ones amongst you (or Mr. jdobbs himself) could elaborate more on the meaning of each of the options regarding 3 categories:
1. Supposed output quality.
2. Supposed output speed rated from 1-8 (in accordance to the number of Decoder selection).
3. User processor type: will an iDCT 64 Bit selection (Floating or IEEE) benefit speed-wise from the use of a 64 Bit CPU under a 32 Bit or 64 Bit OS or does it concern the depth-of-search/quality that the Decoder does quality-wise.

From the DGDecode User Guide

idct : 0 to 7 (default: 0)

iDCT Algorithm.
For more infomation on iDCTs please see Appendix C.
Please see Appendix D for supported CPUs.
- 0 : Use value specified by DGIndex (iDCTs 6 & 7 unavailable in DGIndex)
- 1 : 32-bit MMX
- 2 : 32-bit SSE/MMX
- 3 : 64-bit Floating Point
- 4 : 64-bit IEEE-1180 Reference
- 5 : 32-bit SSE2/MMX
- 6 : 32-bit SSE/MMX (Skal)
- 7 : 32-bit Simple MMX (XviD)


Which iDCT you should use depends primarily on what CPU you have and to a lesser degree, on how accurate of an iDCT you desire. Most people will not be able to tell the difference in quality between these algorithms but they can be easily observed by combining the AviSynth filters Subtract and Levels. All of the available options are IEEE-1180 compliant, except for SSE/MMX (Skal).

Qualitywise: IEEE-1180 Reference > 64-bit Floating Point > Simple MMX (XviD) > Remaining iDCTs.

Speedwise: SSE2/MMX and SSE/MMX (Skal) are usually the fastest. The IEEE-1180 Reference is easily the slowest.




all idct with the exception of 32-bit SSE2/MMX should work on all machines... the 32 bit and 64 bit are not referring to CPU's but on how accurate of an algorithm is used during the decoding.

Hope this helps

[Carpo]

best choices (as fishman has suggested in a diff post) are
3 4 and 7

7 is the default in dvd-rb (3rd for qual)

[jdobbs]

Actually the default is 2. If you choose the "Default" option on the menu, it takes the setting in the .D2V file, which is 32-bit SSE/MMX.

[archaeo]

Originally posted by Fishman0919
Which iDCT you should use depends primarily on what CPU you have

So, optimally I should check the specs on my dual PIII's to know what to set this to? Or just stick with default? Will it make much of a difference, and if so, where?

[Carpo]

Originally posted by jdobbs
Actually the default is 2. If you choose the "Default" option on the menu, it takes the setting in the .D2V file, which is 32-bit SSE/MMX.

thats in the d2v - in the avs its 7 (was b4 0.93) :)

[Fishman0919]

Originally posted by Carpo
thats in the d2v - in the avs its 7 (was b4 0.93) :)

If you do a fresh install of DVD-RB...no former .ini file... the default is idct=2

Originally posted by archaeo
So, optimally I should check the specs on my dual PIII's to know what to set this to? Or just stick with default? Will it make much of a difference, and if so, where?

I think (and this is just IMO) idct=7 is just fine... very little..if any... diff from idct=3 or idct=4 and much, much faster

From the DGDecode User Guide

"Although MPEG is almost deterministic (given a MPEG stream the output should be identical in all decoders), the standard has a degree of freedom when choosing the iDCT to use. That way, the decoder can be more easily implemented depending on the hardware below it. What the standard requires from the decoder is that the iDCT meets IEEE-1180 specs, or in plain words, that the error from the iDCT doesn't go beyond that the ones pointed out in the IEEE-1180."

Which iDCT you should use depends primarily on what CPU you have and to a lesser degree, on how accurate of an iDCT you desire. Most people will not be able to tell the difference in quality between these algorithms but they can be easily observed by combining the AviSynth filters Subtract and Levels. All of the available options are IEEE-1180 compliant, except for SSE/MMX (Skal).


So all of the idct are IEEE-1180 compliant except for SSE/MMX (Skal).... really not going to notice a diff so choosing one that is the fastest makes scents.

[onesoul]

Originally posted by Carpo
thats in the d2v - in the avs its 7 (was b4 0.93) :) It was 7 only if you chose that in dvd-rb.So, optimally I should check the specs on my dual PIII's to know what to set this to? Or just stick with default? Will it make much of a difference, and if so, where? If you are aiming for best quality I'd choose 4 but if you are interested in a good compromise of speed/quality then I'd stick with 7.

[Guest]

The reference IDCT (4) still needs a bug fix. See here:

http://arbor.ee.ntu.edu.tw/~jackeikuo/dvd2avi/refidct/

[Carpo]

Originally posted by onesoul
It was 7 only if you chose that in dvd-rb. If you are aiming for best quality I'd choose 4 but if you are interested in a good compromise of speed/quality then I'd stick with 7.

which is what i said it was 7 but now you can choose what ever idct you like

[archaeo]

Thanks for the feedback,
I also did a quick search and found this test:


http://www.doom9.org/index.html?/idct.htm

[samuelal]

A big big thank you for everyone for the very helpful information!!!

Special thanks @jdobbs for bumping this thread back up :)

Special thanks @Fishman0919 for the quality/speed order reference!

Also @archaeo for digging the material up from the Doom9.org site!

Thanks to y'all.

Samuel.

[Axlemar]

Has anybody had an effect like the one at http://arbor.ee.ntu.edu.tw/~jackeikuo/dvd2avi/refidct/ using idct=4?

[Guest]

There's an arrow clearly pointing to the errored macroblock. If you run any other IDCT, it doesn't happen.

Yes, the bug rarely has this effect, but it is real.

[Axlemar]

ok

[LigH]

I checked them myself on a P4, and got the following results:

http://www.ligh.de/privhome/iDCT_Comparison.htm

(1) MMX, (2) SSE/MMX, and (5) SSE2/MMX are bit-identical, as you can see. The rest has differences which will definitely hardly be noticeable, except for the (4) "Reference", which resulted in swapped DCT patterns sometimes - you can clearly spot them in a "Subtract()" comparison.

[Axlemar]

If you don't mind, what does swapped DCT patterns mean?

[LigH]

The visualisation of the DCT component table looks like this:

http://www.ligh.de/pics/DCT08.gif

If you create a difference clip of two clips decoding the same MPEG material, but using different iDCT functions (one using iDCT=4, another using a different iDCT) via the AviSynth function

Subtract(iDCT4, iDCTx)

you may see now and then some blocks which look like the DCT patterns at (0,1) [-], (1,0) [|], or (1,1) [+] {for your orientation: the top left pattern has coordinates (0,0)}. Just as if those components had inverted values (the wrong sign, +/- exchanged). This result only occurs if iDCT 4 was used in one of these clips. For any other iDCT combination, the deviation (absolute difference) was much lower, and rather randomly distributed.
__

So to answer a PM from samuelal here, too (on-topic questions have to be asked in the thread - PM's are only for private talk outside the board's usual topics): If one iDCT regularly has a higher deviation (difference compared to another clip) than any other combination, it must be the worst implementation, and because you sometimes even see distorsions in the picture directly, this iDCT obviously is broken.

But I cannot tell you which iDCT is the most accurate, just by cross-comparing them against each other. I would instead have to compare them against original (uncompressed) material to give an answer to that question.

Since I once saw comparison pictures in guides on the doom9 website, I just learned: As long as the implementation is objectively correct, and GOPs are not too long, differences won't raise to a noticeable value just because of using one or another iDCT - noticeable artifacts usually have different reasons (e.g., too high quantization). For me, it is fine to chose a fast implementation suitable for my CPU's abilities.

[Guest]

Nice work, LigH. Thank you for the interesting analysis, and the cool picture.

IDCT 4 will be fixed in a future release of DGMPGDec.

[LigH]

Looking forward to it! And: If a "reference algorithm" requires to take time to achieve the most accurate results, then it shall take it! ;)

[samuelal]

Thanks LigH, for the input!

I've decided to take your course of action and changed my settings to the iDCT 5 = 32 Bit SSE2//MMX (Using Athlon64 which utilizes the SSE2+MMX just like the P4, except for SSE3 which my A64 model doesn't poses).

Thanks again.

Samuel.

[TECK]

Here it is an easier explanation, so everyone can have their choice.
32-Bit MMX SSE: AMD Athlon XP / Pentium III
32-Bit MMX SSE2: Pentium IV
64-bit Floating Point: Pentium IV (best image possible, but slower)

I always used iDCT=3 with best results, on my P4.
I'm happy that DVD-RB made possible the choice... :)

[jarthel]

Originally posted by neuron2
The reference IDCT (4) still needs a bug fix. See here:

http://arbor.ee.ntu.edu.tw/~jackeikuo/dvd2avi/refidct/

according to this page, the latest rc for the original dvd2avi has fixed the problem

http://arbor.ee.ntu.edu.tw/~jackeikuo/dvd2avi/

[Fishman0919]

Originally posted by samuelal
I've decided to take your course of action and changed my settings to the iDCT 5 = 32 Bit SSE2//MMX (Using Athlon64 which utilizes the SSE2+MMX just like the P4, except for SSE3 which my A64 model doesn't poses).

If you have an AMD 64 (Like me) idct=7 should be as fast... maybe faster... and with better quality the idct=5

On P4's idct=5 seems to be faster then idct=7

[Guest]

I've released a new version of DGMPGDec with a fixed Reference IDCT (type=4). The changes are by jackei and were derived from his latest version of DVD2AVI.

http://neuron2.net/dgmpgdec/dgmpgdec131b6.zip

[LigH]

:thanks:

I'm still busy with testing and searching for good material which provokes that bug, that I can compare the results to prove the success of the fix. Unfortunately, it takes some time, but this evening, I shall have some shots ready...

[samuelal]

Originally posted by neuron2
I've released a new version of DGMPGDec with a fixed Reference IDCT (type=4). The changes are by jackei and were derived from his latest version of DVD2AVI.

http://neuron2.net/dgmpgdec/dgmpgdec131b6.zip

Dear Neuron2!

First of all thank you very much for letting us know there's already a fix for it. awesome!

1. On the same note and I know it's been pondered many times:
would you consider the latest build which you've post here (xxxx131b6) a relatively reliable one for use in conjunction with DVD-RB Pro v0.93.2 Beta?

2. And on another note:
When using the supplied DGDECODE.DLL file with DVD-RB Pro (v1.1.0) I am getting sporadic BSODs when trying to back up a DVD project.
The BSOD in hand is always: IRQ_NOT_LESS_OR_EQUAL followed by a stop code of 0x000000A, never at an exact spot but always during the encoding process.

I've searched through the internet about this BSOD code, and found several possible causes/solutions for the issue. After trying them all, non of which applied to my situation since:
1. I always disable anti-virus software prior to backup.
2. I always close other TSR resident programs before backing
3. Disabled network connections just in case.

Moving on to the main issue: Since the previous version of DVD-RB Pro of v0.93.1 followed by this thread I've opened, I've been able to successfully backup my personal DVDs while using the iDCT=4 decoder option.
When using the default iDCT=7 or even iDCT=5 (for SSE2+MMX enabled decoding) I've experienced only mixed results which often surcome to the dreaded BSOD in question :)

Furthermore, given the fact that you've just released a fixed iDCT=4 version (though not "endorsed" by jdobbs nor by you for DVD archiving purposes in conjuction with DVD-RB) I can't be more happy to try it if u can suggest it might be a wise choice for DVD archiving purposes and not just beta-testing.

If anyone found a way to overcome this problem without the need to resort to the iDCT=4 (64 Bit IEEE-1180), please share with us.
I don't mind using this option from now on, it's just slower, usually I get on CCE with it x1.55 compared to x2.45 when using iDCT=5/7.

BTW: I've also tried using HC_batch v0.14 w/ iDCT=7 (besides my regular CCE v2.67.0.27 w/ ECLCCE v1.81 setup) with same BSOD results always during encoding process and never during the first/third process.
Also, The PC is not overclocked (specs in sig) and doing on it other stuff such as playing Counter-Strike/Doom3 is smooth and crash free.
----------------------

Again, thank you all for participating in this thread.
(BTW: If the BSOD question is entitled to its own thread, then by all means.).

Samuel.

[jdobbs]

DVD-RB is not compatible with the new .D2V format. The D2V used when backing up with Rebuilder is created by rebuilder (rather than DGIndex.

Stick to the DGDECODE.DLL version that is included with the DVD-RB ZIP file or you will get errors... I've used it on hundreds of movies and never once got an error... it is solid as a rock.

It isn't a matter of "endorsing" the new version -- I endorse it fully and I use the latest version of DGIndex... just not with DVD Rebuilder.

[Guest]

Originally posted by samuelal
would you consider the latest build which you've post here (xxxx131b6) a relatively reliable one for use in conjunction with DVD-RB Pro v0.93.2 Beta? As our esteemed jdobbs stated, it's not compatible with DVD-RB. As to stability, 131b5 added some rather extensive changes (by tritical) to pitch handling designed to make it compatible with the contemplated new alignment rules in Avisynth. Due to their extensive nature, and even though there've been no reported problems since the 131b5 release, I'd be reluctant to declare it fully ready for prime time. It may well be, and I always use my betas for production, but bugs could still appear.

When using the supplied DGDECODE.DLL file with DVD-RB Pro (v1.1.0) I am getting sporadic BSODs when trying to back up a DVD project. That's a tough one. There's the complication of DVD-RB being in the picture, as well as the encoding codec. I've never heard any other report like this so I'd be inclined to suspect your hardware. How old is your power supply (I replace mine every two years!)? I'm not sure how to proceed on this one.

Moving on to the main issue: Since the previous version of DVD-RB Pro of v0.93.1 followed by this thread I've opened, I've been able to successfully backup my personal DVDs while using the iDCT=4 decoder option. When using the default iDCT=7 or even iDCT=5 (for SSE2+MMX enabled decoding) I've experienced only mixed results which often surcome to the dreaded BSOD in question :) "surcome" -> "succumb"?

Well, at least you have a workaround, even if it involves using a buggy IDCT. :) I may soon update the other IDCTs with latest jackei code, but it won't help for your testing due to the aforementioned incompatibility with DVD-RB.

[LigH]

So - as promised:

Between MPEG2Dec3dg (at least - and probably even before) and DGDecode 1.3.1b5, iDCT=4 could sometimes produce such blocks:

0563 (http://www.ligh.de/pics/iDCT4Bugs/0563.png) - 0630 (http://www.ligh.de/pics/iDCT4Bugs/0630.png) - 1426 (http://www.ligh.de/pics/iDCT4Bugs/1426.png) - 1663 (http://www.ligh.de/pics/iDCT4Bugs/1663.png)

Now, with the bugfixed DGDecode 1.3.1b6, the same frames look like that:

0563 (http://www.ligh.de/pics/iDCT4Fixed/0563.png) - 0630 (http://www.ligh.de/pics/iDCT4Fixed/0630.png) - 1426 (http://www.ligh.de/pics/iDCT4Fixed/1426.png) - 1663 (http://www.ligh.de/pics/iDCT4Fixed/1663.png)

(Used material: a DVD trailer of "Mortal Kombat 2 - Annihilation"; pictures contain the result of "Subtract(iDCT2, iDCT4)")

[onesoul]

That's good news. Thanks for the test LigH.

edit: And of course thanks to neuron2 and jackei.

[samuelal]

Good night boyz & girls!

First, a big thank you for all who participated in this thread!
Second, thanks again to LigH for his latest contribution regarding the iDCT=4 issue and .png file samples. :goodpost:
Next, I wanted to share with whoever it may concern that following Neuron2's post,
I did a fresh installation of my OS with some changes (listed below) and as of now (god, I hope I'm not jinxing it or anything) DVD-RB Pro is churning out chapters for my backup.


If your still reading this ;) , here's some more info:
McAfee VS Pro running, Winamp running, Peerguardian 2 running, several Explorer windows open and several other programs too.
This might seem odd to many of you but for quite some time now this hasn't been even an option for me.

Prior to this fresh installation, I've continued my research further and found something that was quite a long shot from my POV but I gave it a shot anyway:
My RAID-0 array is logically devided to 2 partitions: 1x39GB=System (+DVD-RB files etc) + 1x333GB=DVD Backups, Games, etc.
I found several articles which included a possibility for BSODs on partitions which aren't "healthy" in tearms of file system indexing/cross-linking/invalid references etc.

I ran on the 2 partitions the commands: "CHKDSK /F /R" and indeed it found quite a mess on the older partition which hasn't been CHKDSK'ed for over 8 months now (though it has been defragmented several times with a 3rd party software).

This proceedure might have done the trick with other modifications I've done both to my hardware and software installation base:


Mobo: Updated to BIOS version 1.7 .
RAM: Changed timings from: 2-2-2-5-1T-11TRC to 2-2-2-5-2T-11TRC & RAM voltage is now "Auto" instead of 2.65/2.70/2.75. Granted, this might be slower, but from what I see right now it's slower by ~x0.10 and not much else.
Norco's thread, http://forum.doom9.org/showthread.php?t=79602&highlight=3200 has inspired me to finally come-down-to-earth and realize that maybe in fact DVD-RB + CCS/HC can be even more stressful on my machine than CS:Source or Doom3 and maybe lowering my RAM timings a notch down wouldn't be such a bad idea, at least in order to get successful backups.
Latest Windows XP updates: Critical + Latest FrameWork .NET .
Mobo Driver: nVidia nForce Unified Standalone Kit v6.53: Used only Ethernet v4.75 WHQL + SM BUS v4.45 WHQL.
Did not install the dreaded nVidia SW IDE driver (which was installed up 'till now).
GPU Driver: nVidia ForceWeare v66.93 WHQL (Official Release)
Software: Fresh, clean installation of DVD-RB Pro v0.93.2 Beta from the Rockas Installation.
Set a new .ini configuration for DVD-RB without using an older backed up one and set iDCT to 7! instead of the buggy iDCT=4 (Still feel a bit bummed about this that for now there is no support for newer, iDCT4-fixed DGDecode.dll versions).
Software: scrdsfpsboots.exe - This file is also being used on another machine of mine which hosts a 'Counter-Strike: Source' game-server and is intended to stay resident for as long as its DOS-box window's open and sets your machine to run at a higher CPU-cycle refresh rate (it's not speeding up your machine, just the response time of the main CPU-cycle time to somewhere close to 300fps/ticks per second instead of the usual ~90fps/tps).
Just in case you wanna know some more on it: this software simulates what goes on in your OS when you load Windows Media Player and play a media file in it, Load MSN and sign-in or even load an Internet Explorer window and playing a SWF file in it.
I figured it can't do any more harm than already is.

If you've read thus far, thanks again! and maybe cross fingers for me for a sec or two :)

Love this forum!

Samuel.