Musings on DGMPGDec 2.0.0

[Guest]

The two features I'm currently targeting for DGMPGDec 2.0.0 are full cutting support and stream error preprocessing. (Yet later versions will target MPEG-4 and H.264 but let's not get ahead of ourselves.)

So I've been reviewing how DGIndex does its work with a view to adding cutting support. By cutting I mean that instead of specifying a single range that is included in the project, you would be able to specify multiple ranges that would be excluded from the project, retaining proper AV sync, of course.

This raises two major issues that I need to decide about before starting any coding. And that is where users' opinions are really important. I'll describe the two issues and the possible solutions as I see them, together with the implications for usability.

First, there is the issue of the user interface for cutting. How should the user specify the cutting operation? I see two major possibilities. Each is quite feasible, so it's really our free choice which we prefer. First, we have the model of VirtualDub. You set a range and then you hit delete. That section disappears from the timeline and is gone. Second, we could leave all the video on the timeline, but mark the selected parts, in a way similar to the way that the single selection is currently marked. You'd have the equivalent of multiple selection areas on the trackbar, and when you did your save project operation, it would include just the marked sections. But you could still navigate within and view the cut sections.

I prefer the VirtualDub model. It is easier to implement and avoids a few problems. One problem is how to implement the equivalent of a multiselect trackbar. I would probably have to implement a custom control. Another problem is matching the granularity of the select bars to the GOP/frame granularity for large files. You would have difficulty repositioning to the ends of selected areas, or seeing what the ends corresponded to. I can't think of any good reason to leave deleted material on the timeline, and we could contemplate an undo operation for cuts. It would also leverage users' familiarity with the VirtualDub model.

The second issue is that of design and implementation. The current approach used by DGIndex does not require indexing of the loaded file set before allowing navigation. You can position into the stream and then step forward or backward by I picture. This is nice because you can open a file set and start looking at it without waiting for an indexing operation to complete (compare VirtualDub MPEG2). But it has several shortcomings. It doesn't easily allow for frame granularity. It doesn't allow for starting a decode of orphaned B frames properly, as does DGDecode (which has access to the index). It is a really messy code nightmare already and will only get worse. It doesn't cleanly separate decoding from GUI operations. Backward and forward I picture stepping is a kludgy nightmare that is not provably correct and can be shown to be broken in some theoretical cases.

So, while futher hacking of the current architecture to support cutting is possible, I prefer an alternative approach. This is what would happen. When you first load a file set, an indexing of the entire set is performed and stored in a file as well as in memory. Perhaps the file would be called movie.prj. Subsequently, when the project is loaded again, the index already exists and does not have to be generated again.

This .prj file would be the equivalent of a D2V file for the entire project, created without any demuxing of audio or video. Now DGIndex has access to a full correct index and can perform all the things I mentioned above without difficulty: frame accuracy, random access without macroblocking, accurate and straightforward navigation, clear partitioning of GUI from decoding operations, easy support for "no-I-picture" streams, and, of course, simplified implementation of cutting functionality. The new architecture, being better partitioned and frame accurate, would lend itself more easily to the addition of new integrated video functionality.

The downside of course is that you can't just load a file set and start browsing it instantly as you can now. And for a simple index and audio demux, you'd need two passes over the file set: once to index the file set, and again to create the edited timeline and audio/video elementary stream demultiplexes. Remember, however, that the first indexing results are saved in a file and can be reused.

We could, however, implement both methods, at the risk of confusing the concepts and interface. You might open in classic mode or new-generation mode. If you opened in classic mode, you would not have new-generation features. Alternatively, I could ship a simple file set browser based on the current version of DGIndex.

I haven't considered how to sync at cut points yet, but I see that as an implementation issue rather than a usability issue, so we can address that later.

Over to you, dear users. How do you see things?

[Boulder]

I clearly vote for the VDub method of cutting.

I don't know about the indexing though, I process a lot of WAV files and having the audio editor scan the large files before letting me do anything always annoys me. So maybe the option to choose which way the user wants to do things would get my vote - unless it proves to be too messy to code.

[Cyberia]

Dump the classic mode. The only additional delay would be the second pass to create the edited timeline and audio/video demuxes. And that should be VERY fast, shouldn't it?

The total time of project creation shouldn't change much and a lot of functionality is gained. Good Deal.

[iradic]

what about using d2v file for cuting, possible?

you already have a index file right, why creating another one ...

[Cyberia]

Well if I understand what he's saying, the first index would be a d2v for the whole vob, then the second pass would save the demuxed audio/video and the 'edited' d2v. This should be very fast since the second d2v is a subset of the first index, which we have in memory.

[mic]

1st) I would very humbly suggest borrowing a concept from Vegas... Whenever you import an audio file it starts indexing, displaying a waveform when done. If for whatever reason you don't want to wait, there's a cancel button right next to the progress bar.

Could DGIndex work the same way? Open a file and indexing starts, & those who don't want to wait simply cancel. Then indexing could be done at any time, updated (why I'm unsure, but figure someone will come up with a reason), or start deferred indexing when saving a project as now.

2nd) I think some people tend to be more visually oriented, and they're the ones who like myself would immediately say leave all the info on the timeline. But, after thinking about it for a moment, we're also the ones more inclined to use an NLE anyway for the visual feedback, so my vote is go for the V/Dub approach.

[len0x]

May I suggest leaving single pass processing for CLI operations when user doesn't really need to browse or cut video.

[Pookie]

-Have you looked at Mpg2Cut2 ? Might interest you for some ideas - http://www.geocities.com/rocketjet4/

-If the Transport Stream file isn't in good shape, it'll probably be impossible to maintain A/V synch after cutting. Perhaps there should be some function that scans the source file and returns an error message if too much corruption is found?

-That leads to possibly building in a function like Mpeg2Repair, or maybe sending the source file to Mpeg2Repair if a scan finds errors ?

WishList Stuff

-Another cool function would be for the app to search for bitrate changes in the audio portion of the file, assume those are commercials, and automatically cut them out.

[Zep]

I prefer the VirtualDub model.
so do I


So, while futher hacking of the current architecture to support cutting is possible, I prefer an alternative approach. This is what would happen. When you first load a file set, an indexing of the entire set is performed and stored in a file as well as in memory.

The downside of course is that you can't just load a file set and start browsing it instantly as you can now. And for a simple index and audio demux, you'd need two passes over the file set: once to index the file set, and again to create the edited timeline and audio/video elementary stream demultiplexes. Remember, however, that the first indexing results are saved in a file and can be reused.

then you have to fix the errors/drops first before the
first index of the set. So if i have this correct it would be

1) fix the stream (drops and other errors and sync it)
2) Full temp index on that fixed stream
3) Now we can edit at frame level using the first pass temp index
4) Use the first pass temp index - the edit ranges to get our final
edited demuxed files and d2v file.

Do we even need to edit at the frame level? For me the GOP level is fine
since all cuts are in fade to blacks and there are plenty of frames of black.
i.e. the whole gop is black. However, it would be nice to be able to edit at
the frame level. :)

For me the most important thing is fixing the streams and getting the sync
right so do what ever is the best way to make sure that works well.
IMHO If it is easier to fix streams at gop level and get perfect sync then
go that route.

As for multi indexing passes it is not a huge deal. we are only talking
a few minutes more and the second index and demux should go very fast
since you are just using the edit markers/ranges to cut the first pass temp
index down to the final d2v.


anyway, this sounds AWESOME no matter how you end up going :D



Thanks,


Zep

[mg262]

I am against full cutting support in version 2.0.0. The main reason is this:I'm a strong believer in proper partitioning of functionality. There are a lot of "handy" things that could be thrown in, but do they really belong there?There are already GUI programs that will generate lists of trims for AVISynth. Is there some reason why MPEG-2 cutting needs special support?

[Boulder]

As you have to run DGIndex anyway when processing MPEG2, it would be handy to have the cut feature in the same application instead of multiple ones. Just my 2 cents :)

[Doom9]

There are already GUI programs that will generate lists of trims for AVISynth. Is there some reason why MPEG-2 cutting needs special support?It's not so much about the video as it is about the audio.. keeping the audio in synch when cutting is the really complex part. If it were just about the video, I agree with you that AviSynth would suffice, but since video generally goes with audio and there's no adequate solution for audio in case of cutting (no, decoding to wav and using in AviSynth doesn't count.. for starters audio encoders generally don't support AviSynth input, and there's no solution for 5.1 audio plus BeSweet is simply the best audio encoding tool and the audio functionality in AviSynth just cannot compete), cutting support in dgindex does make a lot of sense.

From the two proposed models, I tend towards the VDub one.. multiselection trackbars sound cumbersome (and I can imagine the headaches from a programming point of view). I have another possibility if you'll indulge me: have a separate form with a cutlist, along with "in", "out" and "set" buttons. Once an in and out point have been set, pressing set would add the selected range to the list of material that will be kept. That would spare you from having to make changes in trackbar -> frame selection and the playback mechanism.
I supose full blown NLEs have even more convenient ways, but I consider the above a viable alternative to the VirtualDub model.

Also, I'm in the same shoes as len0x so I'd love to have a one stop cli option for cutting as well.

[mg262]

I suppose I'm very reluctant to see anything that complicates the simplest usage -- load a file, scroll through it to check it, save .d2v . This is what I do in 99% of cases -- for example, when I want to examine any clip posted in this forum.

Edit: Doom9, sorry, missed your reply when I wrote this. Point taken about audio.

[Wilbert]

Sorry to bump in. With cutting support i take it you also mean cutting to a smaller transport stream (ie without any encoding or demuxing)?

[Guest]

Sorry to bump in. With cutting support i take it you also mean cutting to a smaller transport stream (ie without any encoding or demuxing)? I'm using this thread to help decide the requirements. Nothing is fixed yet.

@mg262

Please direct me to one of these GUI trimming tools that you think performs well.

@all

Your comments are being registered and digested. Thank you for your thoughts.

[squid_80]

If the input file (I'm specifically thinking about vobs here) was scanned upon opening, it would be pretty easy to implement some sort of method to select which vob/cell ids to include in the output .d2v file, correct?

[mg262]

@neuron2,
I would personally split screen VirtualDubMod and its script editor, and use the trim-insertion facilities in there. It does involve dealing with one trim at a time, but I find that a small overhead compared to locating the cut positions precisely. There is also this tool: http://forum.doom9.org/showthread.php?p=687842&highlight=avsfilmcutter#post687842

But I have taken on board the point about audio, so please don't pay too much attention to that comment. (Also, independently of the outcome of this discussion, it did also lead me to ask this (http://forum.doom9.org/showthread.php?t=100231).)

[Zep]

I suppose I'm very reluctant to see anything that complicates the simplest usage -- load a file, scroll through it to check it, save .d2v . This is what I do in 99% of cases -- for example, when I want to examine any clip posted in this forum.


It does not complicate anything. In fact it makes the process LESS complicated because the stream fix/edit/index is all done in 1 app
and this 1 app can do a better job if it controls all aspects of what
is the single core objective of getting good to go data for encoding.
Right now you have to cross your fingers and hope that other apps
do not do strange stuff that DGindex barfs on as well as run all these
other apps and remember all the settings and interfaces of these other
apps etc...

i take it you do not edit much because for ME 100% of my cases
i DO edit. ts capping is huge now and that means DGindex should
go along for the ride. HDTV capping is growing very fast and this
means editing and stream fixing are needed unlike DVD ripping where
most of the time the data steam is fine and needs no editing either.

as for clips you want to view NOTHING changes because you do
NOT have to edit the clip. Just index it like you always do.

However, you could also edit the clip and thus index only the part
that you really like and if you turn also turn on stream fixing you get
fixed streams. how cool is that! VERY!

[Zep]

Sorry to bump in. With cutting support i take it you also mean cutting to a smaller transport stream (ie without any encoding or demuxing)?

that would be nice but IMHO that should be at the bottom of feature the list
since i would think most would use the edit/index moer for encoding than
archiving huge .ts files which many are mulicast and may have pid
data you do not care about. Which means DGindex would need a
way for you to choose just the PIDs you want to go into that smaller
ts file etc...

this is of course is one of things projectX does very well.

[Zep]

I'm using this thread to help decide the requirements. Nothing is fixed yet.

@all

Your comments are being registered and digested. Thank you for your thoughts.

Doesn't how you end up coding this depend greatly on if you
allow editing at frame or GOP level?

if gop level only, then you need not do anything to the edited out parts.
you only need to fix the parts we are keeping. (how projectx does it)
then index that.

if frame level then you are sorta stuck having to fix the whole stream
i guess (maybe even index the whole fixed stream?) so we can editing
at frame level?

that is a huge difference on the order of things.

Have you thought about at what level you are going to allow editing?

[Zep]

-Have you looked at Mpg2Cut2 ? Might interest you for some ideas - http://www.geocities.com/rocketjet4/

-If the Transport Stream file isn't in good shape, it'll probably be impossible to maintain A/V synch after cutting. Perhaps there should be some function that scans the source file and returns an error message if too much corruption is found? read the thread and the others too. It has always been about
fixing the stream as well as editing.

however you should be able to edit at the GOP level and then fix
and index just that which you kept (like projectx does it)

[stax76]

So far I've only used multiselect systems so I'm not sure if I'm qualified to vote on this. Did anybody use both systems extensively?

[mg262]

i take it you do not edit much because for ME 100% of my cases
i DO edit. I also edit in almost every case, but after applying temporal filters. But I can appreciate that other people want to work in other ways. In any case the point about audio makes this somewhat academic (unless we find some way to e.g. make AVISynth frameserve to BeSweet).

What are you cutting out of the middle of your sources -- commercials, or something else?

[foxyshadis]

One of the things I was thinking about is maybe making the d2v format more transperently extensible, like, if something supports reading an older version then a newer format shouldn't completely break it. If it would pull out bad data, then yeah, break away, but does that always happen, or is it more often just adding additional information? Some way to keep apps like dvd-rb from failing when someone upgrades their dgindex.

Maybe in the header have chunks separated by a comment with the version number of the lines within. And maybe in the data section mark off extended bits with %c...% with the letter indicating version? I'm sure there's better ways, that's just something I came up with.

I don't actually know, it could be that all the changes would have broken apps that depended on the d2v. I thought I'd throw it out.

[Emp3r0r]

I prefer the multiselect edit mode like ProjectX or HDTV2MPEG2. This is much more comfortable system for editing out commercials or multiple scenes as you can always see the context of one edit to the next.

For example, when I encode CSI, I'm always looking for 4 commercial breaks.

edit: VideoRedo is another app like this, yet the gui is pretty ugly. I prefer clean simple look of DGMPG and VirtualDub.

[mg262]

For example, when I encode CSI, I'm always looking for 4 commercial breaks.Cutting out commercial breaks manually seems like a real nuisance to me; if (as here in the UK) they normally begin and end with a "splash" screen, it would be fairly straightforward for an AVISynth filter to detect them. It could either output the list of trims or just remove the commercials. If the latter, it would probably have to prescan the clip/access frames in a linear order, but this still seems to me to be less tedious than doing it manually. Of course, the audio issue makes that a little redundant, unless you're willing to use avs2wav, etc.100

Edit: I remember reading that often commercials have a standardised, discrete length (e.g. 15 seconds, 30 seconds, etc. ). If that was the case, you could exploitit to avoid the linear order requirement.

[Guest]

THis thread is about how to do cutting, not whether to do it. :)

[foxyshadis]

The way TiVo originally did it was looking for jumps in the RMS power of the audio, which were often very pronounced. Something else that could be exploited is that shows and films will often have a very well defined color range, while commercials are very different (often brighter, bluer/whiter, and a much wider gamut); grain patterns, camera motion, and activity level are also probably fairly regular, but increasingly more prone to bad decisions.

Some shows have splash screens and most don't, but it still sounds useful for those ones. However, there is always a fade or cut to black in my experience, even if just for an instant. Even if it's not perfect, it's a way to find out where to ask "is the next scene show or commercial?" Length could be another good testing factor.

[Guest]

Please stay on topic, fellas. Make a new thread for automatic commercial detection if it interests you. Thanks.

[mg262]

Sorry -- I phrased it badly but I was trying to make a relevant point, namely that manually cutting out the stuff seems to me like the "wrong" thing to be pushing for. I.e. that one of the features driving the reworking of the model is better implemented in another stage of the process, not DGIndex. Hence the rider,Of course, the audio issue makes that a little redundant, unless you're willing to use avs2wav, etc.

[Guest]

I'm not going to argue with you but only observe that you'd better contact the authors of mpeg2schnitt, cuttermaran, and all the NLE vendors to tell them that they are "wrong" for implementing a general cutting functionality.

[mg262]

From that last post I realised that you have a different concept of what DGMpgDec is for to me -- I have always thought of it as mpeg2source with some support structure, whereas (as far as I can see) you envisage it as something much more akin to the packages you mention. In that case, I have absolutely no argument to make -- things that would be feature bloat in the former are perfectly appropriate in the latter. (In any case, if I or anyone else don't want to wait for the indexing we will always have the option of using the last release of version 1.)

Edit: you have probably already considered this, but what about "scan forwards/backwards to scene break" buttons of the kind found in VirtualDub? It seems to me that editing out commercials without these would be relatively awkward.

[Inc]

Hi Donald,

till now when demuxing of Audiotracks is wanted, we have two options (if I catched it right):
1. Choose a track by a tracknumber
2. Demux all tracks

But I think its quite difficult for a user to estimate which tracknumber is related to the wanted specific language to be demuxed.

If youre interested I got an IFO parsing SourceCode where the Languages and the Audiofromat out of Audiostream-IDs can be parsed. So when the user drags or chooses a VOB file out of a DVD folder on the HD, DGindex could automatically look for the VIDEO_TS.IFO in the same source Folder and parse out the Language codes and Audioformats.

[Guest]

If youre interested... Yes, I am interested. Please upload it to my FTP and then PM me with the file name. Thank you.

[Inc]

The Simple_IFO_Parser:
http://home.arcor.de/packshot/Simple_IFO_Parser.exe

The Source:
http://home.arcor.de/packshot/Simple_IFO_Parser_src.txt
(Its written in Purebasic but contains all remarks for understanding the approach)

Beside uploading to your FTP I also posted it in here so others also can access it. Would also be nice for Doom9's MeGUI as I could imagin that its difficult for apps which do access DgIndex via CLI to get the needed Audiotrack Infos.

Hmmmm .... bad thought ... if in the DgIndex commandline just a parameter -a for instance is stored, DgIndex could just only build a txt file where the streams are listened, like known from DVDdecrypter, then the 3parity appl. could parse that one and choose the wanted audiotrack and all other video related params using the common DgIndex CLI acces as knwon.

Greets
Inc.

[len0x]

So when the user drags or chooses a VOB file out of a DVD folder on the HD, DGindex could automatically look for the VIDEO_TS.IFO in the same source Folder and parse out the Language codes and Audioformats.

You do realize that this won't work because VIDEO_TS.IFO contains info for all PGCs and DGIndex at the moment can't stip them out and requires just one PGC as an input. So even if you parse IFO then you don't know what to display to the user.

P.S. parsing IFOs is a bitch, so I suggest using already available libraries like vstrip.dll...

[Inc]

Yep youre right, that was a typo.
I meant the IFO related to the Movie VTS, like
VTS_01_0.IFO

parsing of IFOs is a bitch, so I suggest using already available libraries like vstrip.dll
The example above does handle my VTS_XX_0.IFO Sources well.
If the user in DgIndex does anyway choose the wanted VTS_XX_1.VOB then DgIndex could easely auto-read the related VTS_XX_0.IFO

And adding Subtitle ID parsing wont be that difficult
http://dvd.sourceforge.net/dvdinfo/ifo.html
Video Attributes do start at offset $0100 (2 bytes long)
Audio Attributes do start at offset $0104 (8*8 bytes long)
and Subpicture Attributes do start at offset $0156 (6 bytes long)

[len0x]

Actually I understood what you meant and was talking about VTS_XX_0.IFO... You don't want to encode all episodes of a TV show in one output file do you?

Hmmmm .... bad thought ... if in the DgIndex commandline just a parameter -a for instance is stored, DgIndex could just only build a txt file where the streams are listened, like known from DVDdecrypter, then the 3parity appl. could parse that one and choose the wanted audiotrack and all other video related params using the common DgIndex CLI acces as knwon.


It is a bad thought. IMHO it should be the other way around. DGIndex can take advantage of stream info files produced by other tools and just display info if found. Why reinvent bicycle and build IFO parser into the tool designed for low level video editing/decoding?

[Inc]

Why reinvent bicycle and build IFO parser into the tool designed for low level video editing/decoding?
???
I think DgIndex also is capable of demuxing the audio of the choosen VTS.
It was just a thought incl. providing sources for obtaining Language names of tracks for easier user friendly choosing them in DgIndex - thats all.

Actually I understood what you meant and was talking about VTS_XX_0.IFO... You don't want to encode all episodes of a TV show in one output file do you?
Whats the point? If more episodes are included in one VTS DgIndex does demux the audiotrack anyway as one file, so it would at least be nice to "see" which track does contain the language I prefer.

But ... ;) I don't insist on that idea, so it was meant to be a "thought"

[Cyberia]

Thanks for the contribution, incredible.

I've also suggested this as an enhancement. It's pretty much required if DGIndex ever is to identify audio track specifically. It would also be useful for Subtitle support, which has been suggested as well.

Doesn't Multiangle support also require parsing the IFO?

[len0x]

Whats the point? If more episodes are included in one VTS DgIndex does demux the audiotrack anyway as one file

Let me be more specific: usually users want to put each episode in one file which means that they would have to strip out needed PGC (like ripping in IFO mode) in which case you end up with just one PGC in VTS that you're going to feed into DGIndex. I'm pretty sure more than 90% of users do this now. So imagine you feed this stripped out VTS into DGindex and it parses IFO file and has absolutely no idea which PGC user stripped out before and which languages/subs show to the user. So this feature would be useless in this case. Of couse had DGIndex allowed processing just one PGC from a VTS then yes, parsing of IFO is essential. But not before that...

[FreQi]

@Donald

I am quite accustomed to the VDub interface for cutting segments and cast my vote in that direction. However, with that UI, if I were to mess up and cut too much of the clip, I have to close vdmod and start cutting all over again. So it would be nice to be able to undo or restore deleted segments.

With respect to your second concern, what about leaving DGIndex to open as it currently does, but be able to jump to an I picture sort of like VDub lets you jump to key frames by holding shift and pressing to the left or right. But then, when pressing left or right without holding shift, begin indexing from that position to allow setting a frame accurate cut point? Can that be done?

Even if indexing is only allowed going forward, I think that could be a satisfactory middle ground. It would allow users to quickly open the file set, and scan through it. And those of us who want to commercial cut can quickly jump around to the areas we need, then leave DGIndex to demux the audio and create the d2v when we save the project.

[AllTimeSToneD]

I prefer the multiselect edit mode like ProjectX or HDTV2MPEG2. This is much more comfortable system for editing out commercials or multiple scenes as you can always see the context of one edit to the next.

For example, when I encode CSI, I'm always looking for 4 commercial breaks.

edit: VideoRedo is another app like this, yet the gui is pretty ugly. I prefer clean simple look of DGMPG and VirtualDub.

Thats exactly what i was going to suggest. When you work on ts especially the one from Freetv channels which contain commercials its alot less pain to work with the multiselect system as you can easily go back to your last selection and correct that one instead of having to begin from start on.

Another plus like already mentioned by Emp3r0r is the way you can always see the context of one edit to the next.

I really like the way VideoRedo does its multiselection its similar to Mpeg2Schnitt btw, but the gui is painful, then again its way to keep the a/v content in sync while editing is the best i've seen so far. Maybe its worth a look into it ;)

[FreQi]

One thing I have not seen in any editing application is any information on the audio at the current position in the video. Being able to see some statistical info can really help in deciding the best cut points. Something like the bitrate, number of audio channels and db level would be awesome. You could go nuts and show some sort of oscilloscope, but I don't know if that's something really worth spending your time on.

[Roginator]

If it's going to scan through the whole file, how about tick marks along the timeline showing suspected commercial breaks?

[int 21h]

...I have another possibility if you'll indulge me: have a separate form with a cutlist, along with "in", "out" and "set" buttons. Once an in and out point have been set, pressing set would add the selected range to the list of material that will be kept...

That sounds identical to Mpeg2Schnitt.

Are these changes to DGIndex in response to the fact that Mpeg2Schnitt doesn't handle anything other than Mpeg audio?

[Guest]

That's certainly one point. It has more to do with that MPEG2Schnitt can't serve via Avisynth without intermediate files. And anyway, why shouldn't DGMPGDec be able to cut?

[int 21h]

I can't think of any reason why it shouldn't, but I can think of several reasons why it should :)

Currently there aren't really any good utilities that support such a feat on even simple Mpeg-2 PS files, via commandline or cutlist AND actually do so correctly. There are tons of utilities that simply compute timestamp in relation to SCR, loop through a bitstream seeking to 0x000001BA (pack start?) closest to the timestamp, copy until the next 0x000001BA at the closing stamp or aborting if they reach 0x000001B9. The problems with this stem from those now goofed up SCR values (I guess?) Or I guess the other option is to reconstruct the packs yourself, allowing you to seek more accurately and avoid the SCR issue... I haven't really found a decent example of this around.

My aim of all of this would be have some sort of a simple utility that could do this sort of cutting accurately AND support the cutlist idea to accept a list generated from a PVR app for commercial removal, given that the cutlist was already generated and verified in said PVR app, and it seems like DGIndex is moving that direction... hence my interest.

From an academic standpoint, I should probably just keep reading and figure out how to do some mpeg-2 cutting, but I have confidence that you're already really familiar with how to do it :-)

[int 21h]

Actually, reading through Mpeg2Schnitt, it looks like it just seeks through to sequence headers, I can't really tell though if it does any rebuilding... is any rebuilding even necessary?

If only my Delphi and German skills were better...

[Taelon]

FWIW, I like the Mpeg2Schnitt method of setting in/out points, although I think the "New" button is counter-intuitive, I'd expect setting a valid pair of points to immediately make it ready for a new set. I love DGIndex being able to process .VOB's directly, adding multiple edit capabilites will be icing on the cake.