Why can't DGIndex read IFO files directly?

[bkman]

I do all of my ripping straight from the disks, and manual cutting gets irritating. Are there any plans for DGIndex to parse IFO files? Or if not then why?

[Doom9]

Is it just me or is your post rather demanding? Being a free software, I think it should be you who has to make a compelling case to have a certain feature, and not the author to explain why he adds certain features and not others. It makes little sense to blow up applications by adding code for things that other apps already do and are rather perfect at doing.

[bkman]

No, I'm not demanding anything at all. Perhaps I phrased my question poorly, but you've misread my tone. I was simply asking (if the author is willing to answer) why what to me appears to be an obvious feature is missing from this fine application, and if the author is willing to add it or won't consider it.

As for a compelling case, it seems to me that decrypting individual tracks to hard-drive first when on-the-fly decompression tools such as AnyDVD exist is wasteful, and the ripping process would be much more efficient if it was further facilitated by DGIndex through accurate IFO-based vob/range mapping. To me it makes perfect sense that this is done by the same app which indexes the specified VOB ranges.

This is meant as a humble feature request, please consider it as such.

[neuron2]

I do all of my ripping straight from the disks, and manual cutting gets irritating. Are there any plans for DGIndex to parse IFO files? Or if not then why? I don't know what you mean by "ripping straight from the disks". I also don't know how IFO parsing can help in cutting (because my knowledge of DVD internals is minimal). If you want your feature to be considered, please post a full explanation and specification of how it should operate.

DGIndex is not going to get involved in decrypting operations, if that is what you are suggesting. Why? Because DGMPGDec is a general purpose decoder and frame server, and because I don't want to put it and myself at legal risk. Perhaps you are aware of the situation with DVDDecrypter.

[bkman]

By "ripping straight from the disks" I mean that I do not copy/decrypt the VOB files from the DVD to my hard-drive, but rather parse them with DGIndex and encode directly from the DVD.

As for how IFO parsing can be used in cutting, it is my understanding that the mapping of 'Titles' (like episodes on a season DVD) to their ranges over usually multiple VOB files is contained in that file (for use by the DVD-player). By parsing this file is how Nero Recode for instance allows you to select simply 'Title 1' to rip rather than having to manually find which VOB files it spans. I miss not-having this function in DGIndex. It is nothing to do with actually decrypting.

I'm sorry but I don't know the exact layout of the IFO files, however. I hope you can find this out and the add the feature none-the-less, or at least consider it.

[neuron2]

DGIndex is not going to operate directly on encrypted VOBs on a DVD, because that would involve decrypting.

Given that, why can't you just rip by title using your ripper software?

[bkman]

DGIndex is not going to operate directly on encrypted VOBs on a DVD, because that would involve decrypting.

Given that, why can't you just rip by title using your ripper software?

As I meantioned earlier, there are several on-the-fly decrypters available such as AnyDVD, so from DGIndex's persepective it is already decrypted.

And I would rather see this function in DGIndex because that allows me to use Avisynth filtering and eventually x264 to encode. Can't do that with Nero.

The only other options is using DVDecrypter (which supports IFO parsing) first, which as I said is wasteful (and I don't often have the hard-disk space for a whole DVD), or manually selecting where titles start and end with DGIndex, which is tedious and innacurate, especially since DGIndex doesn't support single-frame stepping.

[neuron2]

As I meantioned earlier, there are several on-the-fly decrypters available such as AnyDVD, so from DGIndex's persepective it is already decrypted. I don't have any of those to assess whether they would work with DGIndex. Is there a good freeware one you can point me to?

The only other options is using DVDecrypter (which supports IFO parsing) first, which as I said is wasteful (and I don't often have the hard-disk space for a whole DVD) So I am to go through all this because you are missing some hard disk space?

or manually selecting where titles start and end with DGIndex, which is tedious and innacurate, especially since DGIndex doesn't support single-frame stepping. How is it tedious? And you can't cut on arbitrary frames in MPEG without re-encoding. Are you asking me to do that too?

[bkman]

I don't have any of those to assess whether they would work with DGIndex. Is there a good freeware one you can point me to?

Not that I'm aware, but AnyDVD does work with DGIndex as I have been using it with it for a while now. The files simply appear already decrypted to any applications reading the DVD.

So I am to go through all this because you are missing some hard disk space?

It would save both space and time, and I assume that I'm not the only one who would benefit from this saving. You don't see the value as a feature to be able to easily select relevant segments to cut? It would even save time for DVDDecrypter users I would think, as one could decrypt a whole DVD at once, instead of each Title they want to encode separately.

And you can't cut on arbitrary frames in MPEG without re-encoding. Are you asking me to do that too?

I wasn't aware that there were cutting restrictions, and no I'm not asking that. I think that IFO parsing would be easier.

Well there is my case, whether you want to do it or not is up to you.

[SeeMoreDigital]

What's the problem with directly selecting the required VOB files.... Like this: -

http://img156.imageshack.us/img156/5026/dgindex1st.png


Cheers

[bkman]

There is no problem in doing that, but then if a Title unevenly spans several VOB's, then I need to seek through the stream and find where it begins and ends and set cut-markers manually.

Apart from being annoying to do every time, this often results in not totally accurate and inconsistent cuts. I'm all for anything which helps automate the ripping process, hence this request.

[SeeMoreDigital]

There is no problem in doing that, but then if a Title unevenly spans several VOB's, then I need to seek through the stream and find where it begins and ends and set cut-markers manually.Are you sure about that?

If that were the case, even DVD Decrypter might struggle to offer an "Main Movie" mode...

Personally I use DVD43 and DVD Decrypter in "File Mode" and rip the "Main Movie".... It's never failed me yet ;)

[bkman]

With several TV episodes on a DVD you have a number or Titles that make up the Main Movie. They have to be indexed separately to get the ac3 for each. Episodes often start and end in the middle of a VOB.

[SeeMoreDigital]

Well at least you are now being more specific about your requirements....

I must admit I've never tried ripping from one of these multi-episode DVD's... I'll have grab one of the kids disc's and see what's what!


Cheers

[setarip_old]

@bkmanThe only other options is using DVDecrypter (which supports IFO parsing) first, which as I said is wasteful (and I don't often have the hard-disk space for a whole DVD)If one is truly "into" video conversion, one of the most basic requirements is to have oodles of hard drive space available, so that there's no need to seek alternative "make do" solutions.

Using DVD Decrypter in "IFO mode", to rip individual Titles/episodes, is probably the de facto standard solution for what you are trying to accomplish...

[neuron2]

You don't see the value as a feature to be able to easily select relevant segments to cut? I have one guy asking for this and hordes asking for DVR-MS support. What to do? :)

[nurbs]

Since dgindex shows vob and cell id it's pretty easy to find the exact end and the beginning of an episode anyway. I used to do that all the time before I figured out I could use ifo mode.

[SeeMoreDigital]

I have one guy asking for this and hordes asking for DVR-MS support. What to do? :)Nah.... Sod em all and add MPEG-4 part 2 and part 10 support instead :D


Cheers mate

[neuron2]

Nah.... Sod em all and add MPEG-4 part 2 and part 10 support instead All right then, I'll get right on it.

[Mug Funky]

for multi-episode rips, what's wrong with using DVDdecrypter, ripping a title at a time and renaming them to the appropriate episode? it doesn't take much time at all.

if it's a multi-ep disc where all episodes are in 1 VTS (these are quite common) you can select individual eps in DVDdecrypter by simply checking/unchecking chapters and watching how the total time to be ripped changes (you'll be shooting for 24 mins in most cases). this is also not hard.

IFO parsing in DGindex would be useful if you've got a whole DVD ripped (in the way the free version of DVDFAB does it), because at the moment i'm making an image of the rip, mounting in daemon tools, then using decrypter. pretty HDD intensive if all you want to rip are subtitles...

[Doom9]

Some people have never heard of 750GB HDs.. but have PCs fast enough so that the few minutes it takes to rip a DVD to your HD significantly slows down the whole process ;) I wonder where I can trade in my PC with lots of HD space against one where the 5 minutes ripping time blow up backup time by 50% ;)
As already mentioned, press F5 and you get vob and cell ids.. with that info it's not that tedious to cut at the proper place and you don't need frame accuracy since cell ids start with an I-frame ;)

[Morte66]

I don't have any of those to assess whether they would work with DGIndex. Is there a good freeware one you can point me to?

www.dvd43.com

This feature would be quite useful. At the moment, if you want to encode four TV episodes from a DVD, you must do four PGC rips and wait for them to finish (say 30 minutes), then you can do all the DGIndex/encode/mux stuff. If DGIndex parsed IFO files you could cut that 30 minutes off the user workflow.

but have PCs fast enough so that the few minutes it takes to rip a DVD to your HD significantly slows down the whole process

This is what devs never seem to grasp, probably because they spend their lives re-encoding the same 2 minute test clips instead of doing actual backups... ;)

There's a difference between computer time and user time. DVD Shrink or Nero only take about three minutes of the user's time to back up a TV DVD, because you put the disc in and specify what you want then wander off. The whole rip/index/MeGUI cycle takes about forty-five minutes of the user's time to do the same thing, because you have to kick off and configure the various stages separately.

[Robot4Rip+batch or MeGUI's one click encoder both get you close, but not quite there.]

[neuron2]

DVD Shrink or Nero only take about three minutes of the user's time to back up a TV DVD, because you put the disc in and specify what you want then wander off. Good. Then you can use them. :)

[Morte66]

Good. Then you can use them. :)

If they supported AssumeFPS(), SSRC(), ColorMatrix(), FluxSmoothST(), RemoveGrain(), or DGIndex/DGDecode's excellent deblocking...

[neuron2]

...all of which you'll be able to set up with no investment of user time, right? :)

[Morte66]

...all of which you'll be able to set up with no investment of user time, right? :)

Again, it's not the time taken directly using the various tools that matters, it's the wait between them. The elapsed time from first inserting the disc to the point where you can leave the software to run on its own.

With DVD Decrypter + DGIndex + MeGUI I spend a couple of minutes actually typing and clicking to do a rip/index/encode, but its spread out over 30+ minutes during which I have to pay some attention to the PC. I do about the same amount of typing and clicking in Nero/Shrink, but it's all done up front. With Nero I could e.g. set up a whole DVD backup while I'm waiting for coffee to brew in the morning and let it run while I'm at work. With the (more technically capable) tools developed around these forums, I'd be half an hour late for work.

If "the Doom9 tools" collectively worked straight off a DVD, reading the IFO to let the user set everything up and then running unattended, it would be great.

[zettai]

While bkman has asked for this in a rather perculiar way, I do think there's a lot of merit in being able to choose groups of vobs and cell selections from an ifo file. There are many many uses that I can think of, such as correctly indexing one 'angle' of a multi-angle stream or picking out a selection of cells from a large and complex file. Of course, it's possible to have dvd ripping software do this for you but if you wanted to rip all of the different angles, titles etc of a complex dvd this could take a significant amount of time with a lot of duplicate data.

The main downside to the idea is that adding this functionality could be time consuming depending on how hard parsing ifo data actually is. I've no idea... nor do I know how hard it would be to apply the data to DGIndex file loading and cell selection.

However, I do think it would be great to be able to rip a disc in file mode and then be able to make separate d2v prjoects based on the ifo file. It would be a very neat and efficient way of accessing data from authored dvds... but yes, it's not a vital part of making a fully-functional mpeg2 indexer.

Ah well :)

[berrinam]

I agree with Morte66/bkman/zettai on the principle that it would be good to have free software with the same capabilities as Nero, etc, (while of course still having the excellent customisability of AviSynth, etc), but obviously it is a lot of work, and I have no idea where one can get the specs needed for IFO-parsing. I just thought I would throw in my vote to show that bkman is not entirely alone.

[tahir]

Hi,
I have already posted my request in DGIndex Development thread. I rip alot of dvd songs. I have to split them in dvd-decrypter using the ifo mode and file spliting set to chapter. Then i create projects for all the chapters. I would like to have DGIndex take an ifo file and create projects of individual chapters.

Thanks.

Keep Up the Good Work :thanks:

[Doom9]

The next think you'll be asking for is audio encoding to mp3, aac, etc, then comes video encoding and then muxing. In the end we're back to FlaskMpeg.
Consider the history of DVD backup: First there were integrated tools like dvdrip and flaskmpeg. The latter did all but rip. In parallel, specialized tools came up for audio and video encoding. Flask always had its issues and it never quite managed to handle everything properly. It also wasn't so actively maintained. One reason for that is complexity... a tool that does everything is considerably more complex than a tool that specializes in doing a certain task only.
Then came DVD2AVI, VFAPI and AviSynth and people turned to VirtualDub for encoding. That complicated matters, but also gave people a lot more flexibility.
Then came the advent of smart frontends that integrated all those tools in a package that was much easier to handle than the spearate parts of the package. GKnot was eventually superceded by AutoGK and today we have highly integrated tools that control a long list of programs.
So today you have the option to use the best in class program for each task and still have it all managed by a single tool, or use all those best in class tools separately.

It makes little sense in blowing up a best in class tool to areas it was never meant for. DVD2AVI, now DGIndex, started out as VOB -> AVI tool but the author quickly discovered that this task meant to many ifs, thens and buts so he focused on frameserving. neuron2 continues his work up to today, and while he considerably expanded upon the original work.. it's still essentially a frameserving tool.. and clearly the best in its domain. Of course if neuron2 would like to expand it to other areas, who am I to tell it's the wrong choice, but since he doesn't appear to be inclined in going that way, I know plenty of good reasons for such a choice.
Today, DGIndex is a generic tool to index MPEG1/2 video streams for frameserving. Adding IFO parsing not only means duplicating the work of the existing best-in class tools for that particular area, but soon thereafter we'll see requests for a similar functionality for other inputs as far as that's technically possible. And then more requests and more requests.

Having been around since almost the beginning and working on my own software, I strongly believe that this open source Recode clone can become a reality, not through amassing features in existing tools that are best at doing a little part, but at intelligently connecting all those tools with a proper frontend. This may require some changes in the tools used, but it will not involve emulating another tool and having to worry about a lot of ifs and buts that this other tool already has to worry about.
Today, IFO parsing isn't just about IFO parsing.. today you also need to be aware of all the corrupt disc structures and if there is a handful of tools that does this properly, why should DGIndex be blown up to emulate those tools?

[OddbOd77]

IMHO this would be an unnecessary feature because by adapting jimmalenko's batch ripping method (http://forum.videohelp.com/viewtopic.php?p=1373527#1373527), used for episodic DVDs, the effect described by the original poster can be achieved.

With a little tweaking the same script can also be used to perform per-chapter processing for DVDs that split episodes that way (i.e. by incrementing /CHAPTER instead of /VTS) plus you can make this a one step process by incorporating the indexing step into the batch and shorten it by using a for...do loop instead unrolling it as per the example.

[bkman]

@Doom9: Imo you are totally exaggerating the issue. I am not asking for some all-in-one Jack of all trades, but simply for grouping two related functions in a way that makes sense and will increase efficiency. As DGIndex already supports the VOB Indexing and slecting ranges, to me it makes 100% sense to add faster and more accurate selection of those ranges for common uses without going outside of the inteded scope of the program.

And just because there already are defacto methods to achieve the same effect, doesn't meant that they are optimal and cannot be improved.

Besides, I see IFO parsing as a fairly trivial thing to implement. But perhaps I am wrong in this.

[neuron2]

Besides, I see IFO parsing as a fairly trivial thing to implement. But perhaps I am wrong in this. Please point me to the specs and sample code so that I can implement this "trivial" thing. Thank you.

[bkman]

Please point me to the specs and sample code so that I can implement this "trivial" thing. Thank you.

http://www.doom9.org/sources.htm
IFOParser would presumably have some code you could work off, and I've managed to find some specifications that may be useful at http://dvd.sourceforge.net/dvdinfo/

Edit: Also, the IfoEdit page has some IFO format information: http://www.ifoedit.com/ifovts.html

And I hope you know that I meant 'trivial' in the relative sense. You are obviously a skilled programmer, and many other apps have implemented IFO parsing. It should be easier than many functions that DGIndex already features.

[neuron2]

Thank you. I'll look it over but I make no promises.

[Amnon82]

@neuron2: Me, maybe I'm not so a skilled coder like you (I learned delphi my self in couple of vacations) have also a IFOParser function added to AutoQ2/3. K, it wasn't me who did it. Kurtnoise did it. I'm only edited his code. You can go here (http://forum.doom9.org/showthread.php?t=110226) for the IfoParser thread by Kurtnoise13 and me.

cheers

Amnon82

[Tatsh]

Usually, I run DVD Decrypter in IFO mode for EVERYTHING and rip parts (like episodes) and put them in separate folders. I select what parts of the video I want and sometimes demux with DVD Decrypter because that speeds up DGIndex's work (if I'm cutting the video (like removing credits) with DGIndex, I keep everything original as VOBs so DGIndex can cut properly).

IMO, that really is the best way to do what you are suggesting.

Oh, and get a new HD. I've got one 400GB (nearly full), a 100GB inside my laptop, and a 500GB (hardly used).

[Kayaker]

Sorry for bringing this topic back, but Donald, what do you think, and how hard do you think that would be for example adding a command line option that takes a file with a list of VOb ID CELL ID ( not neccesarilly contiguous in the strem of course that's the whole point ) and process just them ?

I'm just humbly asking.

I can do that now with great jsoto's PGCDemux after ripping or before ripping with DVDDecrypter.

It's just would be great having it included in the excellent DGIndex.
Maybe it's not that hard, maybe it is. I don't know.

Thanks a lot for your time and the time you spend in this application for the community.

[neuron2]

I don't know how hard it would be until I start trying to implement it. It's already on the development list. But honestly, it's unlikely it would rise high enough on my priority list to get done by me. You're welcome to develop it and contribute it to the code base.

[Kayaker]

Thanks.

I don't have the skill to modify code so complex.

Maybe just a "Hello world" :)

[neuron2]

Don't sell yourself short. This could be the ideal learning opportunity for you.

[Kayaker]

hehe Thanks for the great hope you have in me ...

I got some programming skills and have done something in C long time ago, but looking the code of DGIndex is kinda scary.

I can't even compile the assembly stuff yet ( gotta look what I'm missing for compile those )

But I'll take at look at it, not hoping to accomplish anything useful, but maybe I'll learn something about mpeg streams along the way.

Do you have an idea (as you know well the DGIndex/DGDecode code) if it's prepared just to scan continuous cells or it's prepared to scan/seek random cells ?
(asuming clode GOPS of course )
Both DGIndex and DGDecode ?

I mean, is DGDecode and the d2v file format to "jump" scattered cells ?

[neuron2]

The problem is that only a big single chunk of video is supported. Once you start playing linearly, DGDecode just decodes the next frame in the stream. He has no way to know that the next frames come from a cell you don't want.

It's related to the whole multiple cutting idea. You'd have to redesign quite a lot to support it, which is why I haven't developed the intestinal fortitude to tackle it yet.

[Kayaker]

I was afraid of that.

Do you mean dgdecode does not use the byte index in the d2v file ?
If you make it jump to another offset ? ( I frames of course )

What's the worst that can happend modifying d2file in "illegal ways" ? dgdcode crashing.

I'll check that as soon as I can.

I'm supposedly working here, boring SQL and VB.NET not entertaining video stuff :)

[neuron2]

The index is used only for a random access start to decoding. Once you start decoding, you just keep decoding the next frame in the stream. The requested frame keeps incrementing by one in linear play, and that's how DGDecode knows to just keep fetching. If the requested frame number indicates a jump, then DGDecode uses random access to get there.

What you could do to avoid having to change the code much is force it to always use random access for each frame, and then just delete GOP lines from the D2V as required (they're labeled with the cell id). But the performance hit would be terrible. It has to be redesigned.

I would have done it if AVC hadn't come along. :)

[Kayaker]

You're absolutly right about priorities, AVC is more important.

Are you already working on that ?

That seems prety hard to reconcile with the older code.

[neuron2]

Are you already working on that? You've not been paying attention, eh? I'm at alpha 3 for DGAVCDec.

[Kayaker]

Sorry. I live inside a can :)

Well, after some minor tweaking I could compile DGIndex in both debug and release mode.

The changes I have to do were due to I'm using VS 2003 I suppose.

sqrt(2.0) instead of sqrt(2) in idctfpu.cpp ( due to an new overloaded sqrt it seems )
and remove the " in the custom build step for the assembly stuff.

That's a step forward , eh ? :)

And DGDecode also !!! In a breeze.
Also removing quotes in the custom build step for the assembly stuff.

Lastest NASM 0.98.39 but maybe for some change in VS 2003.

Never mind.

I'll start breaking good and functional code any time soon :)

[neuron2]

That's a step forward , eh ? :) I've been building everything under Visual Studio 2005 for some time now. :)

[Kayaker]

Actually I've tried VS 2005 first, but got some missing direct draw header and read somewhere that they change it or the default location, or something of the sort.

In VS 2003 that header was ok.

But you are talking about you new MPEG-4 is in VS 2005 right ?

Cos the dgindex project is still in old VS 6.0

[Dr.Khron]

Having ripped a ton of TV episode DVDs, I agree that there is a need for this functionality... but I don't think it belongs in DGIndex. As Neuron said, DGindex is a general, all purpose program, and the need in question is very specific.

I think what we need is a seperate app, a "ripping front end" that would cordinate DVDD and DGindex together to crank out a series of VOBs, D2Vs, and WAV files that are ready to go. This would be an enormous time saver for ripping TV episodes.

I guess what I'm thinking of would be a modern version of Robot4Rip, which I used to love using with Gknot. Perhaps someone could whip up a R4R for MeGUI?

[Kayaker]

What I do now with episode stuff is ripping once, then selecting VTS and PGC with PGCEdit or VOBBlanker (to really SEE what is in there. The PGC times can lead to confusions ) and the semi automatically run PGCdemux from the original VOBs into new ones.

It's a hard disk waste because you potentially end using double the space with VOBs.

One PGC per directoy.

But you end up with singles VOBs that DGIndex is happy to process. Automatically if you want.

[neuron2]

Actually I've tried VS 2005 first, but got some missing direct draw header and read somewhere that they change it or the default location, or something of the sort.

In VS 2003 that header was ok.

But you are talking about you new MPEG-4 is in VS 2005 right ?

Cos the dgindex project is still in old VS 6.0 No, I'm talking about DGMPGDec 1.4.9, which has not had its source code released yet. In fact I am using Visual Studio 2005 Express.

[Kayaker]

I see.
It is in release candidate 2.

When do you think it will be ready ?

[neuron2]

I plan to release it early in the week of May 21.