If I had paid for it I would have : 1/ not removed it - 2/ used it more than once. For that price, I would use it 25h a day :-)

so true, i'll settle with dvd lab pro :lol:

£30 000, rather buy a car, rather buy 2 cars, or 3 2nd hand cars.

hmmmm lexus.. bmw..scenarist - dont think sooo! :lol: :lol: :lol:

Bazzy

Here it goes, I found it:
http://cuttermaran.movie2digital.de/...an_e/index.htm

Source is available, have fun. :wink:

EDIT:
I missed your latest post. Have you checked the Big3 Method over doom9? It's complicated but generally works. It envolves re-creating the DVD Structure using Scenarist . Someone created an app (Reauthorist) that reads the original structure and creates a Scenarist script out of it, so you can re-create the original DVD Structure muxing your reencoded video. Of course, then the IFOs won't be correct, so you have to fix using a tool called IFOUpdate.

love to have that in one click tool lol

Coding has begun ;). Right now I'm making a command line tool, I'll convert it into a GUI when decent functionality is there.

At the moment it loads VIDEO_TS.IFO and pulls out most of the information (still have a couple things to do), and displays it on screen. Not very useful right now, but it's a start.

After that I run through the VTS_xx_0.IFO files and do the same thing with them. Once that's done I'll hopefully have some idea how the GUI is going to look, and can implement that before moving on to VOB parsing.

This is a very boring part, turning the IFO file into various classes. The sooner I get it finished the better...

That's a fun part :D
You are using this as reference, right :cool: http://dvd.sourceforge.net/dvdinfo/Go... Go... Go...... :lol:

-kwag

Hmmm ;).

Yup, amongst other things. I spent a couple days searching for and downloading info -- I have a folder with a couple of dozen PDFs I made from web pages...

Some of the fields are still a mystery to me, though, such as the 8-byte "VMG POS" at offset 0x60 of VIDEO_TS.IFO. Any ideas?

Also, "VMG category" at 0x22. Four bytes. Byte 1 is the region code, but the other three are unexplained. They're zero on the IFO I'm using for testing.

Hi Ross,

I don't know what that 8 byte field is either :roll:Take a look here: http://www.videolan.org/cgi-bin/cvsw...pe=text/x-csrc


-kwag

I took a brief look and it doesn't seem they know what it is either ;). I guess it's not important.

Well, I now have 350 fun-filled lines of code representing the various structures found within IFO files. Now I've got to figure out a nice object-oriented interface to it all, because I'll be damned if I'm messing around with mallocs and frees for the whole time.

Oh, and when I try to run this on my PC it won't work, because the x86 is little-endian whereas this PowerPC is big-endian (same as the IFO format). So then I'll have to write little-endian versions of most of those structures...

Sigh ;).

Make that 460 lines. I forgot a few :roll:

http://www.roebling.de/sshots.html (commercial product)
Or:
http://wxglade.sourceforge.net/ (Free!) ;)

Both rely on wxWidgets ( http://wxwidgets.org/ ) which carries a great license :D

"The wxWidgets 2 licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWidgets, and also those producing proprietary software." ;) ;)
http://www.wxwindows.org/newlicen.htm


-kwag

Yep, I use wxWidgets a lot. It's not perfect but it's way nicer than MFC (is anything less nice than MFC?), and it also means I don't have to learn Cocoa, Carbon or Objective-C.

By "interface" I meant an object-oriented interface to the C structures I've made, to make accessing all the data easier and less bug-prone (memory deallocation handled by the destructors, for example, so I can't forget to free stuff).

A well-designed interface to the data should make things much simpler. A badly designed interface will get in the way. I guess I'm going to have to do some "designing" now :roll:

;)

No :mrgreen: Yep. Exactly :) Sorry :!: :oops: I misunderstood you :roll:
What about encapsulation your structures in "Lua", and then wrap your C/C++ code aroud it :idea:
This way, you can "script" your application, and bind your data objects with a typeless and very fast (probably the fastest!) interpreter, and you don't have to worry about malloc, etc.
http://www.lua.org/notes/
http://www.lua.org/notes/ltn005.html

-kwag

I've been playing with DVD Rebuilder recently. Very, very nice program. Seems to mux perfectly. Shame QuEnc isn't quite ready for production use yet (or maybe it was just my settings)...

It's along the lines of what I'm planning for my utility, except I figure if you're going to all the trouble of parsing IFOs and VOBs and demuxing streams, and then remuxing them all back together again, you might as well offer similar functionality to DVDReMake and let the user blank out cells and mess with PGC command tables.

I'm not entirely happy with encoding each cell seperately -- it certainly isn't optimal -- but the only way around it would be what I suggested before: joining the cells together and encoding, then splitting them. But that raises the problem of how to split on P- and B-frames, which is not easy in the least.

Still, it's a very cool utility (I've initated a transfer to my PayPal account so I can make a donation to the author) and combined with DVDReMake serves my needs until my tool is ready... ;)

Did you look at pgcedit also ? This tool has features that might inpire you. Again, see on doom9.

I am not sure right now, but I think that if you give CCE the exact chapter time in chapterlist, It will put a I-Frame there in the cutting point.

Never heard of it. Thanks for the tip :).

It's supposed to, but from what I can gather it's often out by a few frames.