DGMPGDec 1.4.0 Final! [Archive] - Page 5

Guest

21st June 2005, 15:27

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

21st June 2005, 16:06

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

EDIT: Nevermind

Teegedeck

21st June 2005, 16:09

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.

Guest

21st June 2005, 19:01

@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

22nd June 2005, 02:14

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.

Guest

22nd June 2005, 02:20

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

22nd June 2005, 02:23

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. :)

Guest

22nd June 2005, 02:25

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

fccHandler

22nd June 2005, 02:44

iNFO-DVD

22nd June 2005, 15:58

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

Guest

22nd June 2005, 16:22

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

22nd June 2005, 16:47

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

Cyberia

22nd June 2005, 18:35

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

iNFO-DVD

22nd June 2005, 19:19

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

22nd June 2005, 19:26

Teegedeck

22nd June 2005, 20:47

@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

22nd June 2005, 20:54

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

22nd June 2005, 21:00

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)

Guest

22nd June 2005, 21:42

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.

iNFO-DVD

22nd June 2005, 22:08

got ya, well I'm happy with it, works fine for what I want to do, cheers again.

jang0

25th June 2005, 12:35

What about people that write DOS batch files?

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

I just tried in a DOS command shell sth. like:

lame.exe --alt-preset 128 "C:\Path with Spaces\test.wav" and it worked. So there must be a way. Without qoutes it doesn't work, then it says: Could not find "C:\Path".
Just as a little hint. (and I think that's how most CLI programs handle file paths in (Win)DO(w)S)

Guest

25th June 2005, 13:39

Leak

25th June 2005, 16:54

@jang0

lame.exe does not receive the quotes in its argument string; DOS strips them. We want DGIndex to receive the delimiter character. If it was simply the case that we wanted to be able to pass spaces in filenames, it would be easy as you say.

And there I was thinking all the fuzz here was about being able to pass a filename with spaces to DGIndex... :confused:

Or, in other words - what do you need the delimiter characters for if you know the whole next parameter is a complete filename?

If this is about the comma separated list of file names - how about doing it like loads of GNU software does it?

DGIndex -IF "path to\file1" -IF "path to\file2" -IF "yet another\path to\file3"

etc.?

np: MC Frontalot - Which MC Was That? (demo)

Guest

25th June 2005, 21:05

We have a working solution and compatibility with existing tools. I'm not interested in spending any more time on it, nor do I think it is worth it.

stax76

27th June 2005, 00:02

We have a working solution and compatibility with existing tools

compatibility shouldn't be the problem, pseudo code:

if commandline contains "-SD=" or
commandline contains "-IF=" or
commandline contains "-BF=" or
commandline contains and so on then

use old syntax and parser
else
use new syntax and parser

PetraPan

27th June 2005, 00:46

hi there, might be a silly question, but if i demux a vob file that was ripped of in ifo mode with decrypter, the generated stream information file shows me audio delay of -80, but the filename of the demuxed audio shows 0 ms, so what is the correct value? is this stream delayed, yes or no? would be nice if somebody can help me out here, so that i can encode this audio with proper delay in besweet.

cheers :)

Trahald

27th June 2005, 01:28

imo i think you should go with dgindex' value. DD can sometimes be wrong. (i am assuming the 0ms delay was from dgindex.)
Oh..and welcome to the forum.

Moitah

27th June 2005, 04:12

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...
You're talking about the video on Shades Of Purple? Hmm, DGIndex has problems with that:

http://www.moitah.net/misc/m2msopmpg.png

VLC/Windows Media Player play it fine, but other software has trouble. Just a weird file I guess, but I will upload it if anyone wants.

EDIT: Screenshot is from 1.4.0RC4

Guest

27th June 2005, 04:26

You know I'm going you to ask you to upload it, so why waste time asking me? :)

OK, here we go. Please upload it to my FTP server and tell the file name here. Thank you.

Moitah

27th June 2005, 04:43

You know I'm going you to ask you to upload it, so why waste time asking me? :)

OK, here we go. Please upload it to my FTP server and tell the file name here. Thank you.
:)

Okay, it's up: m2msophcd001.mpg

Guest

27th June 2005, 04:44

Muchos gracias!

I will inspect it right now.

Guest

27th June 2005, 04:54

I like the popcorn explosion. And the chicks are hot.

OK, so this one had 2.2 MBytes of garbage before the first pack header. What if the next one has 20 MBytes? 200 MBytes? Where are you getting these things?

I have to think about this.

EDIT: She sounds like Britney.

Cyberia

27th June 2005, 05:39

Don, create a small dialog with some kind of progress bar (or maybe just a label saying "Scanning for Pack Header...."), and a Cancel button.

Then you can scan the whole file for the pack header, and users know DGIndex isn't locked up, and they can abort if desired.

Seed

27th June 2005, 05:43

OK, so this one had 2.2 MBytes of garbage before the first pack header. What if the next one has 20 MBytes? 200 MBytes? Where are you getting these things?

Just a quick thought. How about an "Extended Option" mode in "File Open" menu (like in Virtualdub), where an option "scan aggressively for first pack header" where DGIndex will scan even the whole file (or an user specified Mbytes) looking for first pack header.

In the default setting, DGIndex scans only the first 200 Kbytes. If it fails to find first pack header, a pop-up box will tell the user something like "File unrecognised. You may want to try open it with Extended Option".

Edit: Cyberia posted while I wrote. A progress bar is nice.

fccHandler

27th June 2005, 07:51

m2msophcd001.mpg
That's the one! I don't remember it having 2.2 MBytes of junk, but it was quite a while back. I dug up my old CD of this, and in fact the current VirtualDub-MPEG2 won't open it. You would have to raise the SEARCH_SYSTEM_LIMIT #define and recompile.

Now it's all coming back to me. Interesting that they gave the file an .mpg extension. And yes the chicks are hot, but better than Britney IMHO. :D

EDIT: VLC/Windows Media Player play it fine, but other software has trouble.
Hmm, I almost overlooked this statement. I don't have VLC installed, and on my computer WMP6.4 and WMP10 won't play it. (Indeed, NOTHING I have right now will play it.)

Moitah

27th June 2005, 09:06

Hmm, I almost overlooked this statement. I don't have VLC installed, and on my computer WMP6.4 and WMP10 won't play it. (Indeed, NOTHING I have right now will play it.)
I think it's because I see a filter called "Ulead MPEG Splitter" being used. When I use the overrides in MPC to disable that, other MPEGs play fine but not this one.

SeeMoreDigital

27th June 2005, 10:19

dlight

28th June 2005, 14:05

When I demux and try to load into VDubMod I get the error "Old or Obsolete D2V file". I tried to fix the D2V file but DGIndex says that there are no errors.

dlight

28th June 2005, 14:07

You guys might be interested to know that after running the "m2msophcd001.mpg" clip thru' VCDGear (using it's mpeg -> mpeg setting), it's possible to generate a fully working (and in sync) file. That in-turn, can be recognised by all your media players and DGIndex again :D

Cheers

I am not sure what you mean can you elaborate? Let me elaborate. Does this only concern this particular file or have you discovered a method of resyncing bad files?

Guest

28th June 2005, 14:33

When I demux and try to load into VDubMod I get the error "Old or Obsolete D2V file". I tried to fix the D2V file but DGIndex says that there are no errors. I don't know what you are doing so I'll guess.

You cannot load DGIndex D2V files directly in VDM. You have to serve the D2V through an Avisynth script using DGDecode. If you are in fact doing that and you still get the error, then be sure that you are using matched versions of DGIndex and DGDecode, and that the D2V file is generated with the correct version of DGIndex. You can't always load D2Vs created with earlier versions of DGIndex, because the D2V file format sometimes changes.

dlight

28th June 2005, 15:11

I don't know what you are doing so I'll guess.

You cannot load DGIndex D2V files directly in VDM. You have to serve the D2V through an Avisynth script using DGDecode. If you are in fact doing that and you still get the error, then be sure that you are using matched versions of DGIndex and DGDecode, and that the D2V file is generated with the correct version of DGIndex. You can't always load D2Vs created with earlier versions of DGIndex, because the D2V file format sometimes changes.

I am loading the avs script. The versions of DGIndex and DGDecode are the ones in the most recent RC4 set so that shouldn't be an issue. I'll try demuxing again and see what happens.

Guest

28th June 2005, 16:17

I am loading the avs script. The versions of DGIndex and DGDecode are the ones in the most recent RC4 set so that shouldn't be an issue. I'll try demuxing again and see what happens. Sometimes you pick up an unexpected version of DGDecode, for example, from your Avisynth plugins directory. Use the info=1 option of DGDecode to display the version number and verify that it is the one you think it is.

calinb

29th June 2005, 06:22

I cannot use dgindex to re-open a project file, previously saved with the same version of dgindex (currently using RC4). This functionality was lost sometime within the last few revs. :( The d2v file works fine with dgdecode.dll, GKnot, etc. Source is an mpeg2 transport stream.

Sorry if this is a known bug (or change in behavior). I seached this thread but don't have time to search any further right now. :)

Guest

29th June 2005, 07:26

I cannot use dgindex to re-open a project file Load project is not restoring the PIDs. I will fix it. Thank you for pointing it out.

calinb

29th June 2005, 16:47

Thanks, Donald! Your work is much appreciated and I love the new features.

Guest

30th June 2005, 05:24

Here is RC5. The changes versus RC4 are as follows:

* Legacy audio conversion functionality was removed as discussed here: http://forum.doom9.org/showthread.php?t=96524.

* LPCM support was improved: 1) 48K/96K, 16bit/24bit, and mono/stereo are now supported. 2) The format info is included in the filename and the info dialog. 3) Demux Track and Demux All now work for LPCM (no special handling).

* The D2V format version is now checked when loading a D2V file.

* IDCT support was fixed: 1) The IDCT algorithm specified in the INI or D2V file is now not automatically promoted (e.g., previously if you had IDCT=1 in the INI file and then started DGIndex, you'd end up with IDCT=3). However, the IDCT is scaled down if it is not supported by the processor. 2) A bug in DGDecode was fixed that caused SSEMMX to be used when SSE2MMX was requested. 3) The IDCT algorithm is now consistently numbered between the CLI, D2V, etc.

* Fixed setup of PIDs when loading a D2V file (fixes calinb's issue).

* Increased the parse depth for a first pack header to 2,500,000 bytes and added additional emulation protection (fixes Moitah's weird popcorn explosion MPEG1 stream).

* Added audio processing to the Quick Start guide.

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

I hope this can go final soon. :)

Cyberia

30th June 2005, 14:39

Don, the IDCT menu item only displays the supported IDCT types, so why would it fall back if the type was unsupported?

Do you mean, in case someone edits the INI or D2V and designates a unsupported value there, then we fall back?

Guest

30th June 2005, 14:43

Do you mean, in case someone edits the INI or D2V and designates a unsupported value there, then we fall back? Yes, exactly.

iNFO-DVD

1st July 2005, 10:32

I apologise if this shouldn't really be posted here :confused:

I've noticed in this post and other posts when people have a problem with a VOB or MPG file a clip/sample is needed. I know there's programs to already do it but I was bored so quickly knocked this up.

It's really simple, just load in the file and tell it how much MB you want to take out to a seperate clip. Simple as that and it's only 36K.

Nothing is changed in the file/sample, just copied exactly as was in the original.

SampleSlice.NET (http://www.clonead.pwp.blueyonder.co.uk/aviprogram/SampleSlice.NET.zip)