DGMPGDec 1.4.0 Final!

[neuron2]

Please stop your upload. I don't have enough space. Thank you. I've already got 70Meg of it. It should be enough.

[neuron2]

Originally Posted by Teegedeck

Hm, RC3 seems to crash on this VOB.

Your vob has about 630 KB of stuff before the first pack header (mostly zeroes)! So it was not detected as a program stream, because I was looking only at a much smaller portion of the beginning of the file to look for pack headers. I have the fix already and will release it tonight. Thanks for pointing this out.

[Cyberia]

Try using a progam called "Chopper XP" to cut the vob. See if that 'repairs' the vob too.

EDIT: Nevermind

[Teegedeck]

Originally Posted by neuron2

Your vob has about 630 KB of stuff before the first pack header (mostly zeroes)! So it was not detected as a program stream, because I was looking only at a much smaller portion of the beginning of the file to look for pack headers. I have the fix already and will release it tonight. Thanks for pointing this out.

Brilliant! Sorry for stopping the transfer belated, I had to leave the PC unattended for some time and only looked at the error messages of FireFTP when coming back.

[neuron2]

@Teegedeck

Where did that VOB come from? Did you rip it from a DVD? It appears to have been made with Sonic ROM Formatter. But what is all that junk before the first pack header? I'm a little worried about having to parse into 1 MByte of streams looking for a pack header due to the possibility of start code emulation.

[fccHandler]

You can virtually eliminate mistakes by verifying the marker bits and fields. Pack headers are especially robust because they have several marker bits which must be set and at least one field (mux rate) which cannot be zero.

Also, it's my understanding that a valid MPEG-2 program stream MUST have a pack header at least every 0.7 seconds. The number of bytes you'd have to search depends on the bitrate, but there should definitely be a finite point where you can declare the stream invalid.

[neuron2]

Thanks, fccHandler. I just independently wrote code to check all the marker bits, but I didn't think to check the mux_rate.

So here is RC4. It fixes Teeg's issue and adds the promised -SD CLI option.

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

[fccHandler]

Something else I just remembered... In program streams a pack header must be followed by either a system header or a PES packet. You can verify those too if you want to be really robust.

[neuron2]

Did you go that far? Of course, I am very partial to robust coding.

[fccHandler]

Not quite that far. And I think I set my search limit at 200 KB, and only because I once encountered a video file (on a commercial CD) that had like, 150+ KB of junk at the beginning. Nothing I had could open it at the time, but I was convinced it had an MPEG inside and I eventually proved it with VirtualDub-MPEG2.

As I recall, you were supposed to install some stupid player software on the CD, which I wasn't keen to do. It was an M2M CD, BTW...

[iNFO-DVD]

I added DGIndex to avi.NET, changed some stuff in my program because of the update and done some testing.....

I am very very happy

Rather than use the -SD=! as a "!" can be used in a filename/path I tried -SD=* and have got to say it worked a treat, really pleased, now I can use any path/filename via the CLI.

Thanks Don, I know it probably seemed a trivial request at first but I know it was for the best

Thanks again

[neuron2]

That really surprises me, because I thought the DOS shell would try to perform globbing on * characters. I'll try that tonight just for grins.

EDIT: I just googled around and found that it is the DOS commands themselves that process the wildcard characters, and not the shell itself! So your approach should be fine, as long as you don't use a 3rd party shell that does globbing.

[iNFO-DVD]

I've just tried everyone..... * < > : \ / ? | they all work

[Cyberia]

How is it possible that < > and | work? These should be shell-interpreted.

[iNFO-DVD]

Well without looking into it and having a quick guess I wonder if it has anything to do with the fact I'm not calling a dos/console app but just passing parameters to a windows GUI program?

[iNFO-DVD]

Infact Don, you could probably drop the -SD completely as quotes works fine. Just tried, SD="

example:

-SD=" -AIF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB" -OF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB.TEMP\GO_01_PGC_01_1" -Exit

No problems at all

[Teegedeck]

@Donald: If only I knew. I've found it on my constant quest for high-quality trailers in MPEG-2 format some 4 months back...

[Leak]

Originally Posted by Cyberia

How is it possible that < > and | work? These should be shell-interpreted.

They are, but if you execute an .exe-file using the appropriate system calls you're not even getting near a shell; those are interpreted by the/a shell before using the same system calls...

np: Stewart Walker - Sprites (Grounded In Existence)

[Leak]

Originally Posted by iNFO-DVD

Infact Don, you could probably drop the -SD completely as quotes works fine. Just tried, SD="

example:

-SD=" -AIF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB" -OF="C:\Documents and Settings\Wayne\My Documents\GO_01_PGC_01_1.VOB.TEMP\GO_01_PGC_01_1" -Exit

No problems at all

Yeah, AFAIK the command line gets passed exactly as it is to the newly started process. You can get it using the GetCommandLine() function.

np: Stewart Walker - Chimera (Grounded In Existence)

[neuron2]

Originally Posted by iNFO-DVD

Infact Don, you could probably drop the -SD completely as quotes works fine. Just tried, SD="

What about people that write DOS batch files?

I think I'll just leave it as is now.