VOB ID byte Changer Tool packet question

[VidHack]

Hello,

I am working on a VOB tool, sort of a VOBedit "JoinClips" mode tool on steriods. Its written in VB. I have a quick question, (perhaps MPUcoder is reading this), if I scan the VOB packet stream, then find NAV DSI Packet Header (7 bytes) 00 00 01 bf 03 fa 01. Skip the next 24 bytes to the VOB ID (2 bytes), alter it, skip 1 byte to the CELL ID (1 byte), then alter it. Since I am doing this in a BINARY access mode reading byte-by-byte, what is the MINIMUM amount of bytes to the next NAV DSI Packet Header? I realize this a varying number, but if I had a minimum number, I could advance the FIle Pointer that number, and start hunting for the next Header pack. This would probably speed up the code 75% since I wouldn't have to read every single byte and do a check for the header sequence.

Thanks for any input from anyone, and any ideas for the tool. I will release it as freeware with source code, if I ever finish it. I only mess with this when I get some time and to learn a bit more of VB.

Well, I tried to enclose a screenshot of the tool, but pressing the IMG button on the top of this page does nothing? So, how do I do that also?

VidHack

[mpucoder]

Just a quick hint, look at vobu_ea in the DSI.

[VidHack]

Thanks for the tip. It lead me in the right direction, but not exactly in a straight line. Your website packet info is actually a bit confusing on these bytes. To quote it, "vobu_ea [4bytes] VOBU end address - relative offset to last sector of VOBU". The first problem is the use of the - (minus sign) or are you using it as a "Dash" symbol? Its confusing cause it appears as its defined as a Mathmatical Expression. As, if you have to Subtract the offset from the VOBU end address. I hate to sound super anal about this, but isnt this technical information?

Anyway, after trolling for other resources, I now have a working formula. It seems to be flawless, and I have spent many an hour cross checking the NAV DSI Packet start addresses using a HEX editor. Finding the next packet and applying the formula, it works on the calculator. I have to ADD 1 to the VOBU offset byte for it to compute correctly, and I used 2048 for the sector size (800 HEX). Your packet info made no reference to this, but on another website that explained VOBdump it did. Here is the formula, and perhaps you can explain this 1 byte annomoly?

All values in HEX:

A = Current PES NAV DSI Packet Address
B = vobu_ea offset

((B+1)*800)+A= Start address of next NAV DSI Packet

Why do I have to add 1 to B? Thanks for all your Technical help.

VidHack

[mpucoder]

That's a good point about the notations, and I'll change them to not look like formulae. Why they chose end_address over size_in_sectors is anyone's guess, but ea+1 = size. ie if you have 3 sectors, they will be numbered 0, 1, 2, with 2 being the end_address. There are many tables in DVDs that use ea and not size.
The information was meant to supplement info published in books, notably DVD Demystified, where you find a lot of info about the physical and logical arrangement of data (including the sector size of 2048, there is an indirect mention of that at http://www.mpucoder.com/DVD/dvdmpeg.html ) There are more detailed explanations in the works (the "how does" and "how to" articles just started) plus a series of pages arranged like Windows Explorer to explain the logical storage.
Some other info to save you some grief later on, and speed things up: Packs are sector-aligned, meaning ther first 3 bytes contain the start code, and you do not have to examine every bit looking for it. In fact, doing so will get into trouble. Only MPEG video/audio packs are guaranteed to have no more than 22 zero bits before a marker bit is inserted (preventing false interpretation of a start code). The private streams do not follow this convention, as their contents are DVD specific, and not intended for (and not delivered to in a player) MPEG decoders.
Each pack contains one packet, except for the NAV pack and any pack which needs filler (the last pack of each stream in a VOBU is where these can be found). That means audio/video/subpicture/NAV are never mixed in one pack.