Comments about DIKO 2.44

[vmesquita]

Share your comments here! 

[c.kirkby3]

Finally DIKO feels solid and stable again.

I have just done a conversion all seemed well, with aften and hcenc (quality based) very quick.

Will report back later on the end result as i'm at work :-P and i just radmin'd into home to check.

Is there a noticeable difference between multipass (2pass) and quality based with hcenc?

And what are the differences in transcoding time?

[vmesquita]

Thanks c.kirkby3! 2 Pass should take nearly twice as much as quality based. But 2pass will give you a exact filesize, while Quality Based will (by its definition) cause variations in filesize. Specially in my tests, quality based tends to oversize with HC.

[rendez2k]

So far in my small test, auto resolution finder is fixed! I'll do a full test later....

[MASE]

I get this error when HCEnc is finished running :

Cannot find video or audio data. Ensure that your PIDs are set correctly in the Stream menu.

Seems a HC problem, will totally reinstall and go back to 2.35 to doublecheck.

[Aielman]

Hooray! The giant file problem seems to be fixed. Thanks, VM.

[Scrotos]

I still have to dig up screenshots of the random green edges, however...

Vista.

I hate Vista.  But I'm forcing myself to learn it and use it.  I prefer Win2K, but video card drivers aren't being released for that anymore since it's end of life.  And XP isn't being sold anymore, so... Vista it is.

But why am I mentioning Vista?  Because of UAC, which I have l not disabled in the interest of learning how to play nice with Vista.

See, I have this problem.  C:\Program Files\ is a protected folder.  And, by extension, so is C:\Program Files\Diko\ and C:\Program Files\Diko\scripts\

What this means is that when I go to File Explorer and navigate to that folder and double-click on, say, C:\Program Files\Diko\scripts\dvd\Cartoon_Anime.avs to change the word "convertign" because I'm anal-retentive, when I try to save that text file I get the error:  Cannot create file [path]\Cartoon_Anime.avs 

So even though I am an Administrator (not a User or Power User) and the file is not read-only, I cannot save this file.  The ONLY way I can do this without trashing Vista's "security" is to manually launch Notepad with the "Run as Administrator" option and then open the .avs file directly through Notepad's file explorer.

This is infuriating.  It's not just Diko, either.  I have this problem trying to edit .ini files with my IRC client, for instance.

Possible solutions would be to never use a user other than "Administrator", possible to force ownership of all the files in my hard drive (though that might screw something else up), or disable UAC and the protected folders somehow.

However, you might want to address this in a future version of Diko.  Instead of referencing scripts and whatnot in the %PROGRAMFILES% location (which doesn't seemed defined in my copy of Vista, oddly enough), perhaps store the scripts in %LOCALAPPDATA% or %ProgramData% or something.  Just... a different location that users can actually tweak the scripts with less pain.

I can only see Vista being used more and more in the future, so you'll probably run into this problem with more and more users as time goes on.  I assume most "power users" are already disabling stuff in Vista and might not see this issue, but newer users won't be disabling stuff as much and would run into this.

It's something to think about, at least.  I used http://vistaonwindows.com/environment_variables.html as a reference but I am not certain how valid that info is.  I was too lazy to look on MSDN or TechNet for the appropriate info.

I don't know if you want to use %homepath% since it's changed between XP and Vista, I think.  If you wanted to change things anyway, that is.  But it seems like this is the security model that Microsoft is pushing on its users, so we're probably stuck with it.

[vmesquita]

@Scrotos
This seams really an annoying problem. I always tried to make DIKO the less "messy" possible, don't putting stuff in register except for the scritcly necessary (avisynth and xvid) and keeping everything togheter. But it seems that I'll have to change it so Vista can be happy.  Added to to-do list.

[Scrotos]

Well, I'm not into windows programming so I don't know how much you'd have to stuff in the registry, but yeah, painful.

I installed 2.44 full install over 2.42 full install and I got an error about bad parameter -2

I think it's the --2 after the aspectratio 4:3 part. 

20:04:52: .\encoders\QuEnc\QuEnc^n.exe -cores 4 -i "F:\dvd-temp\movie0.avs" -o "F:\dvd-temp\movie0.mpv" -b 3964 -maxbitrate 8000 -priority 5 -dc 8 -mpeg2mux noaudio -scene -extreme -maxbframes 2 -nointerlaced -aspectratio 4:3 --2 -auto -close

I tried both cartoon_anime and high_quality.  I think my wife tried both FreeEnc and QuEnc, I've only just tried QuEnc (as you can see from my log snippet above).

I also got this: (in the DOS window that pops up when doing some of the audio processing)


Error 64 : Unable to get ogg.dll interfaces

please download and install the Ogg Vorbis DS (DirectShow filter) :
http://doom9.org/software2.htm#filters
BeSweet v1.5b31 by DSPguru.
--------------------------

[01:13:03:136] transcoding ...


Is this because I'm still processing after QuEnc failed?  I just wanted to see how large some extracted audio was getting, 1.2 GB it was, heheh.  Anyway, do I need to install OGG Vorbis stuff?

[Scrotos]

Oh, btw, when QuEnc died on me, it left DGIndex running as a process.  And while things went merrily on their way with the audio extraction and processing, I ended up with some working files that were locked by that process and I couldn't delete them:

112 movie0.LST
  0 movie0_000.M2V
  0 movie0_001.M2V
  0 movie0_002.M2V
  0 movie0_003.M2V
 112 bytes total

This isn't a "omg it's a bug!" post, just an FYI in case someone else runs into this.  Going to task manager and killing the DGIndex process removed the lock on those temporary files and I was then able to delete them just fine.

[Scrotos]

Last spam for now.

20:04:52: .\encoders\QuEnc\QuEnc^n.exe -cores 4 -i "F:\dvd-temp\movie0.avs" -o "F:\dvd-temp\movie0.mpv" -b 3964 -maxbitrate 8000 -priority 5 -dc 8 -mpeg2mux noaudio -scene -extreme -maxbframes 2 -nointerlaced -aspectratio 4:3 --2 -auto -close


For the --2 bit, is that something I can fix myself until a new release fixes this for me?  If so, I am not sure where to look for ... oh hey, maybe in quenc.ini in the diko/encoders folder.
Bah.  Changing the

1PASS=-1
2PASS=-2

to

1PASS=1
2PASS=2

didn't work.  Bummer!  I'll try downgrading to 2.43 in the meantime.

edit:  2.43 full install didn't work for me when I installed it over 2.44, same error.  I then installed 2.42a full install and now it's working just fine.  I wonder why I got this problem but no one else did... funky.  So I'm running on 2.42a for now.

[Darksoul71]

@Scrotos:
Your commandline looks strange indeed.
I just grabbed the latest DIKO 2.44 (Non-Gold) and tried an encoding with QuEnc^n and my CLI was normal -> only -2 for two pass mode.

I checked the encoder template for QuEnc and everything looked fine.

You could have a look at the QuEnc^n logfile to verfiy that the commandline given by DIKO is really corrupt.

But I got another problem: QuEnc^n bombed out with an error: Floating point support is not available. This was caused by UPX (re)compression in older versions. 

@VM: Did you package QuEnc^n and HCEnc^n uncompressed with DIKO 2.44 ?

Cheers,
D$

[Scrotos]

I'm going to try completely wiping out my old install and doing a fresh install of 2.44, instead of installing 2.44 over 2.42a.  Maybe that's my problem.

And poop, I deleted that ^n logfile already.  I'll also have to give that a check if the fresh install doesn't fix it.

[Darksoul71]

@Scrotos:

And poop, I deleted that ^n logfile already.

 

No prob ! It´s just that QuEnc^n protocols the whole CLI given by DIKO.
This way we could have nailed down wether DIKO logged something wrong or if QuEnc(^n) was really called with a wrong CL.

Oh, btw, when QuEnc died on me, it left DGIndex running as a process.  And while things went merrily on their way with the audio extraction and processing, I ended up with some working files that were locked by that process and I couldn't delete them:

112 movie0.LST
  0 movie0_000.M2V
  0 movie0_001.M2V
  0 movie0_002.M2V
  0 movie0_003.M2V

This behaviour is quite normal. Something went wrong with QuEnc^n during the encoding process with QuEnc. Since I do not do any further checks on the M2V segment, QuEnc^n simply started DGIndex to merge the segments. Since some of the segments might have been blocked by died QuEnc instances the complete process failed.

[vmesquita]

I installed 2.44 full install over 2.42 full install and I got an error about bad parameter -2

There was a bug in the template that was working fine until 2.43 only because there was another bug on DIKO code. I fixed in 2.44, but you must install DIKO Free 2.44 and then upgrade to gold.

I also got this: (in the DOS window that pops up when doing some of the audio processing)

Error 64 : Unable to get ogg.dll interfaces
...

Is this because I'm still processing after QuEnc failed?  I just wanted to see how large some extracted audio was getting, 1.2 GB it was, heheh.  Anyway, do I need to install OGG Vorbis stuff?

No. BeSweet sometimes issues this error because OGG stuff is not included in DIKO. You can install if you want but since it's not used it will not alter the result. Audio is big because it was being extracted uncompressed. 

@VM: Did you package QuEnc^n and HCEnc^n uncompressed with DIKO 2.44 ?

Yes. But I just realized a problem. For some unknown reason, if you install over a previous install, the older, packed files are kept, at least in the test I ran here. You must uninstall older version (or delete its folder) to have the unpacked files.