@Maven: question about demuxing procedure

[Bluedan]

Prolog:
At current state there are a lot of rippers that have grand problems to demux a subtitle stream (assuming stream processing selected) so that it can be processed further without errors. The most obvious gain of this method is speed.
Smartripper must be set to "demux to extra vob" to produce working subs.
DVD-Decrypter, which made very promising advances lately, currently doesn't demux correctly at all.
SubRip merely apologized with "bad header package at LBA 1" which is also the message shown, if you used "demux to extra file" within SmartRipper.
The golden choice in your programme is to select a substream, deselect any checkbox standing for header issues as well as "never split vob". The result is a 21MB file - far to big compared with Smartripper. BTW, SmartRipper has severe problems to cope with subtring IDs which produces the "time restart from 0 in middle of DVD" bug mentioned in SubRip

Main:
Hm. My question to you is what exactly happens with the selected substream ,especially the header, if you select demux, or nothing at all? I know there's a lot of header information in VOB files. Is it the problem to finf out which data is needed for Subtitles"

epilog:

[LIGHTNING UK!]

I know that post wasnt aimed at me, but I feel I can add a little here.

The stream is currently processed in the same way as all the other streams. The vob specific headers are removed.

It would seem, that in actual fact, all of the sub ripper programs need those headers to be left where they are. This isnt a problem and takes but 1 minute to implement.
I dont really do 'dvd ripping' myself, and so have never actually tried to use any of my programs output with any of the available tools. I rely on you lot telling me if something doesnt work!

I have asked around and nobody has given me any instance where the original format of the subtitle stream DVD Decrypter extracted could be used. For that reason, I have made a permenant change so that all the headers are always included. Because this effects everyone that tries to use the program for subtitles, I see it as a fairly important fix and as such will release 3.1.2.0 in the next day or so.
I might try and add a couple of other requests by then so it will be actually worth downloading for most people, not just the sub rippers :)

[Bluedan]

hey busy Lizzie, doesn't bother me at all, you're really accommodating!
Indeed I see no existing purpose for the demuxed subtitle streams in their current state. So, I'd really appreciate the change you've indicated.
And maybe to meet more aproval you should mention it in the changelog pointing out to speed gain. I think not many people use it the way I do, just because the standard guides - yes Doom9 !- don't stress that possibility.

I'm looking forward to your achieves, Lightning, did I mention that the surface is extremely convenient ??

[maven]

i understand your question (was it a question?)...

for the record (in vStrip that is):
- DEMUX writes only the data portion of the sector (i.e. the payload) for a single stream.
- Everything else still writes something resembling VOBs (e.g. 2k aligned sectors, many different streams in one file).

Additionally you can check "Only keep GOPs", which corrupts the Video-Stream, but still retains the timing information contained therein.

Demux is needed if you for example need a RAW AC3 stream to mux into a file (e.g. AVI).
The other mode(s) are usefull if you need to do post-processing (capture subs, decode audio).

usually, when decrypting, i create 2 files:
- video stream only (as vob, not as m2v) (big file)
- video GOPs only + audio + subtitles (as vob) (small file)

[Bluedan]

...it was. Thanks for your reply.
So my choice with vstrip to seperate them all (vid;aud:subs) compared to your personal way would be checking subtitle stream and GOP for sub output.
BTW, what did you mean with that pop-up "Don't choose more that one." when positioning mouse pointer over demux check box.
Truly unintelligible from my side...

[maven]

you don't want to demux more than one stream into a single file...

[Bluedan]

ehh,
"Don't choose more thaN one" ??

;)