PgcEdit and multitasking/mouse sensitivity problems

[Chetwood]

I'm doing a lot of multitasking on my system and when using tools like DVD Shrink or DVDlab-Pro it's possible to set them to low priority from within the program. However, I can't do that with PgcEdit and I'm wondering if this can cause any trouble in the output when converting dvd video files to ISO. Working on several other programs (Winamp, Firefox, Mail) together with PgcEdit slows down everything notably on my machine (old 800 Mhz Celeron) which I can handle, the questions is if this *could* lead to "hickups" in the video?

Secondly, when right-clicking on items in the Pgc Selector screen to add new dummy pgcs from the context sensitive menu I often accidentally add more than one because the menu obviously is popping up too fast or to easily and - more importantly - I can select items from the menu with the right mousebutton too! So when I right-click to call up the menu this click also selects whatever option is under the mouse cursor the moment the menu pops up. In other programs this cannot happen since you can only select menu items with the left mouse button.

Problem is that I also haven't found a way to delete a dummy pgc from the pgc selector pane. Isn't it possible?

[lark]

i don't think multitasking can cause hickups in the video.
just don't run anything else on background, when you are BURNING the dvd.

for the 2nd problem, have you tried options-popup menus on right mouse button released.

no, there's currently no easy way to delete dummy PGCs. i wish there was...

regards
t :)

[Chetwood]

Originally posted by lark
i don't think multitasking can cause hickups in the video.
just don't run anything else on background, when you are BURNING the dvd.


Actually I do it all the time since I only burn at 4x speed and both the software and my burners internal buffer stay at 99% so there's no problem.


Originally posted by lark
for the 2nd problem, have you tried options-popup menus on right mouse button released.


Yes, thanks for hinting at it, I hadn't checked the new options from the new version yet. You cannot use the right mouse button any longer to select items from a menu, that's how it should work.

[r0lZ]

Right, lark. When creating the ISO, the speed doesn't matter. But when DVD Decrypter starts and begin to burn, you should avoid multitasking, as with every burning program. Note that DVD Decrypter increase his priority when burning, but this is not sufficient to guarantee a safe burn, especially if other running programs are doing many disk accesses.

Right again: the "popup menus on right mouse button released" option has been added to avoid this problem. But take care: it introduces some other problems! I can't do more.

Partially wrong: You can delete the last PGC in the current domain (see in Utilities menu), if and only if it is in a menu domain, or, in title domain, if it is a dummy PGC belonging to the last Title number, and if there is more than one PGC in the domain. You may also delete a whole menu domain with 'Remove menu'.
In other words, you cannot delete a whole titleset, and you cannot delete a PGC if there are other PGCs or Titles after it (because the references to the following items will be wrong).
It should therefore be possible to delete the PGC you just added with 'New Dummy PGC'.

[lark]

Originally posted by r0lZ
You can delete the last PGC in the current domain (see in Utilities menu)...

and now you are telling this to me.
after doing things like this with ifoedit :-(
and it was hidden all the time in the utilities menu ;-)
maybe i should read the manual... shame on me.

regards
t :)

[r0lZ]

Don't be ashamed! The manual is not updated anymore. Shame on me! :o

[Chetwood]

Originally posted by r0lZ
Right, lark. When creating the ISO, the speed doesn't matter. But when DVD Decrypter starts and begin to burn, you should avoid multitasking, as with every burning program. Note that DVD Decrypter increase his priority when burning, but this is not sufficient to guarantee a safe burn, especially if other running programs are doing many disk accesses.

I doubt that. When burning on my system DMA is enabled so the CPU is not very much involved and can be used for other programs if you've got sufficient memory. Of course, you should not be copying large files to your source drive, still as long as the writing buffer (either writer's and software) don't ever run empty (as is the case on my system when burning at 4x) the quality should not differ from any burn done on an otherwise idle system.

BTW, how about enabling PgcEdit to "stream" DVDs to the writer so one does not have to make an ISO on HD before burning? Is this possible with mkisofs?

[r0lZ]

Originally posted by Chetwood
I doubt that. When burning on my system DMA is enabled so the CPU is not very much involved and can be used for other programs if you've got sufficient memory. Of course, you should not be copying large files to your source drive, still as long as the writing buffer (either writer's and software) don't ever run empty (as is the case on my system when burning at 4x) the quality should not differ from any burn done on an otherwise idle system.That's what I mean when I say "especially if other running programs are doing many disk accesses." I agree that multitasking is not the problem per se.

BTW, how about enabling PgcEdit to "stream" DVDs to the writer so one does not have to make an ISO on HD before burning? Is this possible with mkisofs? Unfortunately, it's not possible. Mkisofs allow to send the data in the standard output (it's a Unix program!), but DVD Decrypter needs a real file to operate. I have asked LIGHTNING UK! to add a stdin option in DVDD, but he doesn't want to support that. Maybe if there are enough users asking the same thing, he will change his mind...

[Chetwood]

Originally posted by r0lZ
Unfortunately, it's not possible. Mkisofs allow to send the data in the standard output (it's a Unix program!), but DVD Decrypter needs a real file to operate. I have asked LIGHTNING UK! to add a stdin option in DVDD, but he doesn't want to support that. Maybe if there are enough users asking the same thing, he will change his mind...

Well, he was also not very cooperative when I suggested making DVD Decrypter's write mode more visible to the average user claiming Photoshop also wouldn't offer any function on it's main GUI either. Go figure. Did you start a thread or as by mail? What feature would I have to ask for?

How about asking Joerg Schilling about new features in mkisofs, or maybe it's already in there? OK, I know of Joerg's tendency to start bogus discussions (been lurking on German usenet for a long time) but maybe he'd be interested.

BTW where can I read about the differences between ISO and BIN images? I always thought they were holding the same information, i.e. all stuff that is on a disc, being an image of one. When I ripped one of my old original game CDs to HD to play it mounted in Alcohol, UltraISO said "Multi-track information will be lost if using standard ISO format". How come?

[r0lZ]

I have started this thread (http://forum.dvddecrypter.com/index.php?showtopic=16679) in the DVDD forum.

The problem is not related to mkisofs. It is able to stream the ISO, as it is the software used by CDRecord, on Linux.

For now, the ISO image must exists on disk, and be closed, or DVDD will not accept to burn it. My suggestion is to use the special file handler called 'stdin' (Standard Input) instead of the real file, so that the ISO could be generated and burn on the fly, using the so called 'pipe' mechanism. But there are limitations when using stdin: the data are sent sequentially, therefore, you cannot seek at a specific point in the file, or you will loose the beginning. And I understand that a burner program must know the size of the ISO before processing, to verify if the ISO will fit on the current media.
There is an option in mkisiofs to calculate the size of the ISO image, to be able to pass that information to the burner program via a command line option. This CLI option must also be added in DVDD.

But LIGHTNING UK! wants to verify the ISO before starting the burn process. I'm not sure it's actually done: I have tested that, and DVDD has burned a bad ISO without complaining.


ISO/BIN: I don't know exactly what are the differences between these formats, but I can say that ISO is theorically a format that contains everything needed to burn the DATAs, but without some tracks used internally by the hardware players and burners.
BIN images are images of the data themselves, without header. You need also a CUE file to store other parameters.
Also, there are many variants in the ISO format. Some of them are more complete than others.
Nero NRG images are also ISOs, but with some minor differences. (You may change the extension to use them with other programs!).

A good information on ISO images is difficult to find on the net, because there are so many variants. Have a look at the homepages of mkisofs, Img Tools, Daemon Tools, etc... Also, I suppose you will find useful to read the burning forum, here at D9.
[EDIT:] CDRInfo.com may be useful, too.

[mpucoder]

There's more to it than that, too, that maybe Lightning is not aware of. Windows programs, that is those written with a WinMain and using the libraries provided by Microsoft for Visual C, cannot access stdin, stdout, or stderr.
Trust me, I went around and around on this with Muxman, several forums dedicated to coding, and Microsoft. There are code example that say they can do it, but it reality they open up a seperate "console" and cannot use the one that launched the program. This is because the start up code for a program declared as "windows" not "console" gets detached from the initiator. This is also why you can type another command while Muxman runs, as it is now a seperate task. Using "Start /w" to initiate the program overrides that, but do you want to start DVDDeCrypter that way?

[Chetwood]

Originally posted by r0lZ

A good information on ISO images is difficult to find on the net, because there are so many variants. Have a look at the homepages of mkisofs, Img Tools, Daemon Tools, etc... Also, I suppose you will find useful to read the burning forum, here at D9.
[EDIT:] CDRInfo.com may be useful, too.


Basically I wanted to know whehter the bin/cue format is as platfom independet as is the ISO format. Seems I got some reading up ahead. Also gonna check out the thread at DVD Decrypter forum.

Originally posted by mpucoder
There's more to it than that, too, that maybe Lightning is not aware of. Windows programs, that is those written with a WinMain and using the libraries provided by Microsoft for Visual C, cannot access stdin, stdout, or stderr.

...but do you want to start DVDDeCrypter that way?


Mmmh, I don't know, I've seen something like this only in Audiograbber (http://www.audiograbber.de/redir/?l=agfreesetup.exe&mirror=3) so far:

http://img178.echo.cx/img178/1128/audiograbberstdin9ug.png

[lark]

but isn't that the other way round?
lame is reading the stdin and it's not a win app...

regards
t :)

[mpucoder]

That's true, Lame is a console application.

[r0lZ]

Originally posted by mpucoder
There's more to it than that, too, that maybe Lightning is not aware of. Windows programs, that is those written with a WinMain and using the libraries provided by Microsoft for Visual C, cannot access stdin, stdout, or stderr.
Trust me, I went around and around on this with Muxman, several forums dedicated to coding, and Microsoft. There are code example that say they can do it, but it reality they open up a seperate "console" and cannot use the one that launched the program. This is because the start up code for a program declared as "windows" not "console" gets detached from the initiator. This is also why you can type another command while Muxman runs, as it is now a seperate task. Using "Start /w" to initiate the program overrides that, but do you want to start DVDDeCrypter that way? Oh yes. I forgot how idiot Windows can be sometimes. :angry:

Does that means that it is impossible to use the pipe syntax with a windows app? Normally, the second program in the pipe should share the same process and std file handlers with the first one, no?

Also, I will launch the command from Tcl/Tk, which is able to read the stdout and stderr of the programs it has launched (although not with ALL programs). The 'exec' command has a Unix like syntax (with '&' to force the app to run in background, as a new process).
But I know cases where the app is automatically detached from the calling process, even if you don't specify the '&' argument. This is often the case when the program don't have command line syntax.

Anyway, this Windows limitation is a good reason for Lightning to not implement the stdin feature. :(

[mpucoder]

Yes, impossible using any of the Visual C products (Visual C, Developer Studio, Visual Studio, etc) and standard library - it is the library that causes this. There are other compilers and other libraries that are able to remain in the parent context.
Supposedly, according to Microsoft, there is a conflict between the two api's, so you have to make a choice when starting a project. Considering how many layers of i/o there are, I believe them.

[Chetwood]

Originally posted by lark
but isn't that the other way round?
lame is reading the stdin and it's not a win app...

Right, I just wanted to say that this is the only prog using stdin/stdout I've seen so far under Win. OTOH I wouldn't mind having an ugly DOS window or something as long I could save some disk space ;)