FixVTS Version 1.603 is available

[jeanl]

FixVTS Version 1.4 (now 1.603)
Here's (http://www.videohelp.com/~FixVTS) the latest release of FixVTS.
This is a tiny update with a couple improvements.


FixVTS now zeros out offset 0xC0 in video_ts.ifo when video_ts.vob is removed. This is for Nero to stop complaining about a reallocation error.
Fixed problem that occurs when a PGC Cells has the right pointers, but wrong VCID ("When a Stranger Calls" for example).


Jeanl

[President]

FixVTS Version 1.4 the latest release of FixVTS.
This is a tiny update with a couple improvements.
Jeanl

Great thank's, Jeanl!

[setarip_old]

FixVTS now zeros out offset 0xC0 in video_ts.ifo when video_ts.vob is removed. This is for Nero to stop complaining about a reallocation error.Your making the "VIDEO_TS.IFO" more compliant should eliminate tons of future postings (at many forums) by DVD Shrink users who have it set to automatically use NERO to burn. (It's also one less thing to blame NERO for)

Well done ;>}

[jeanl]

Your making the "VIDEO_TS.IFO" more compliant should eliminate tons of future postings (at many forums) by DVD Shrink users who have it set to automatically use NERO to burn. (It's also one less thing to blame NERO for)

Well done ;>}
well, that's the hope!!!
Thanks!
Jeanl

[jm1647]

@jeanl - Thanks !!! This lil program just keeps getting better and better :D

[blutach]

Thanks Jean - making up for Ner0's errors :)

Regards

[setarip_old]

@blutach

Hi!FixVTS now zeros out offset 0xC0 in video_ts.ifo when video_ts.vob is removed. This is for Nero to stop complaining about a reallocation error.This statement by jeanl seems to indicate that the "VIDEO_TS.IFO" was flawed/non-compliant, not that NERO was in error (Actually it seems that NERO was properly identifying the error)...

[Adub]

There has been a small update.

FixVTS 1.401
* FixVTS now zeros out offset 0xC0 when any menu vob is removed (not just video_ts.vob). This is for Nero to stop complaining about a reallocation

[jeanl]

@blutach

Hi!This statement by jeanl seems to indicate that the "VIDEO_TS.IFO" was flawed/non-compliant, not that NERO was in error (Actually it seems that NERO was properly identifying the error)...
No, I'm not saying that the IFO was non-compliant, because I don't know whether it is or not! The specs are blurry (so I've heard) and I have never seen them. The fact is that nero's the only soft that complains about this problem (as far as I can tell). Does that mean they're right or does that mean they're being a pain in the arse? You be the judge. My take is that they're being a pain.
Jeanl

[mpucoder]

If offset 0xc0 of the VIDEO_TS.IFO is non-zero then a VIDEO_TS.VOB file of non-zero length is required. This is one occasion where the spec is very clear.

[jeanl]

Well then, my bad!
Jeanl
I suppose this is also true of all the menu vobs?

[setarip_old]

@mpucoderIf offset 0xc0 of the VIDEO_TS.IFO is non-zero then a VIDEO_TS.VOB file of non-zero length is required.Am I understanding correctly, that this is what NERO is "pointing out" (properly) when it generates a "file reallocation" notification?

[mpucoder]

Yes, jean, this is also true of VTSM. If offset 0xc0 of any ifo is non-zero it indicates the location of the menu vob file within either VMG or the VTS and is, therefore, allocating it space.

While this condition (0xc0 non-zero without a menu vob file) is an error, it is NOT a re-allocation error. Those are generally Nero improperly disagreeing with the authoring program's allocation. Case in point declaring a reallocation error when offset 0x0c is not the sum of the ifo, bup, and vob file lengths in sectors less one.

[jeanl]

Thanks mpucoder!
jeanl

[blutach]

In light of mpucoder's info, perhaps the word "errors" in post 6 should perhaps have been "deficiencies".

Regards

[TuRiSOft]

Hi @all !!! I'd like to ask jeanl to add an "OPEN" button in FixVTS next release . It could help all of us in our Linux/wine migration . Thank for all your work !!!

[jeanl]

TuRiSOft, I'll make a note of it. I added that to menushrink for the very same reason...
jeanl

[jeanl]

_____________________________________________________
FixVTS Version 1.403
Here's (http://www.videohelp.com/~FixVTS) the latest release of FixVTS.
This is another tiny update with a couple improvements/fixes.


Fixed a tiny bug that messed up the Last VOBU start sector in some rare cases (last VOBU with only 1 sector).
The VTS(M)_C_ADT and VTS(M)_VOBU_ADMAP pointers are now set to 0 if the tables are empty. This prevents Shrink from crashing on empty VOBs.
Added an "Open" button to the UI.
FixVTS now zeros out offset 0xC0 when any menu is removed. This is for Nero to stop complaining about a reallocation error.


Jeanl

[jm1647]

Once again, Thank You, Thank You :)

[blutach]

Thanks Jeanl - this is one great tool to fix badly authored DVDs.

Regards

[TuRiSOft]

Thank for the Open Button !!!

[President]

FixVTS now zeros out offset 0xC0 when any menu is removed.
Thank's, Jean!

Sorry for the extremely stupid question. Where is it "offset 0xC0"? I took a HEX-editor, opened a VIDEO_TS.IFO, found a 0000C0 hex-address, but this byte was always equal to zero without dependance of VIDEO_TS.VOB existence. Thank's.

[jeanl]

Look at it using IFOEdit (much much easier!). THen click VMGM_MAT and you'll see the offsets and their values. The offset is off the top of the file, I'm surprised it was 0. Don't forget it's a int, so it's four bytes. The first byte might have been 0, but probably not the other ones...
Jeanl

[President]

Look at it using IFOEdit (much much easier!). THen click VMGM_MAT and you'll see the offsets and their values. The offset is off the top of the file, I'm surprised it was 0. Don't forget it's a int, so it's four bytes. The first byte might have been 0, but probably not the other ones...
Jeanl
Many thanks, Jean!

[jeanl]

FixVTS Version 1.5
Here's (http://www.videohelp.com/~FixVTS) the latest release of FixVTS.
This is another tiny update...


If the CLI is used to tell FixVTS where to write the log, FixVTS appends to the log, rather than erasing it.
Increased length of navpack array to avoid crashes on some twisted DVDs.


Jeanl

[dirio49]

Thanks Jean:thanks:

[blutach]

Thanks a million Jean.

Regards

[linx05]

Thanks heaps! This looks good.

[President]

FixVTS Version 1.5
Great thank's, Jeanl!:thanks:

[setarip_old]

@jeanlIncreased length of navpack array to avoid crashes on some twisted DVDs.What titles (and regions) fall into this category (I've not experienced this waith any rips on which I used FixVTS)?

[jeanl]

IIRC, there was on title in the czech republic, that was extremely tortured when it comes to DVD structure. FixVTS was crashing due to an inordinary number of navpacks. Of course, that wasn't the only thing wrong with it. I don't remember the details though... :(
Jeanl

[setarip_old]

Thanks for the info ;>}

[Sumster]

I did find one rip which VTSFix had problems with (perfect track record otherwise).

I ripped Memiors of a Geisha using the lastest DVDFAb Decrypter (beta 9). I still have the files on my hard drive. It plays fine from the directory, therefore the rip is working.

1) When I import this into DVD shrink, the main movie is correct, and I have 0.01mb in unreferenced materials. Shrink has problems at the beginning of the movie and the buffer keeps rising until it crashes.

2) I run VTSFix with both the first and second boxes checked -- it deletes the first 5 mintues of the movie and the player gets stuck within a few frames. The movie, however, can run through Shrink with no crashes.

3) I run VTS with only the pointer LBA option checked, and the unreferenced option unchecked. Now, the first 5 minutes of the movie show up in the "unreferenced section" (it is about 130 mb). When I play the movie, it starts 5 minutes into it ignoring the unreferenced portion.

4) I run VTS with neither checkbox on -- now the whole movie shows up in the "unreferenced" section in Shrink. It plays perfectly well, but Shrink still has the buffer problem at the beginning of the movie.

Just food for thought....

Sumster

[Sumster]

I apologize, I meant "FIXVTS" above... :)

[blutach]

I'd start again with RipIt4Me (http://www.ripit4me.org/). This sounds more like a DVD Fab Decrypter issue than a FixVTS one.

Regards

[jeanl]

Sumster, your experiment is quite interesting. Was that a R1 disc? I should try and reproduce what you saw.
If FixVTS behaved the way it should the results should be:
Experiment 2) The player should run normally, and Shrink should be OK too. this isn't what you get
Experiment 3) The player should play normally, Shrink should show a lot of unreference material. this is what you get
Experiment 4) The player should play normally, Shrink may not be able to open/process the rip. This is what you get

So the only thing that's incorrect is the fact that experiment 2) does not play well in your player. Does it play normally in a software player? The symptoms make me think it's a "get vts sector" problem (where the sectors pointers in the IFOs are screwed up). If you still have the files, you could run FixVTS as in experiment 2), the open and save in PGCEdit. Then burn and test...
If that works, then I know that FixVTS failed to fix something in the IFOs. Just in case, make copies of the IFOs before and after PGCEdit....

Jeanl

[jinjin_jp]

I found interesting thing.
By correcting(reducing) cell adress of VTST_PGCITI (or VTSM_PGCI_UT), the parts become to unrefferenced materials when reading in DVDShrink.

And DVDFabDecrypter has the feature that has mismach between VTST_PGCITI(VTSM_PGCI_UT) and VTS_C_ADT(VTSM_C_ADT).

Is there anything references?

[jeanl]

Yes jinjin_jp. Shrink is smart enough to detect that only a portion of a cell is referenced, and it puts the rest in unreferenced material, which is surprising because nobody knows for sure whether it's legit to have a mismatch between VTS_C_ADT and VTST_PGCITI. Also, you'll find that if you extend the pointer to go beyond the cell, the entire PGC can become unreferenced! There's no logic to that, just a quirk in Shrink...
jeanl

[laserfan]

Memoirs R1 is a Sony disc, and when I first ripped it (with RipIt4Me 1.4.3 and FixVTS 1.401) it retained 6 or 7 cells at the beginning of the movie which caused "jumping" to the end of the disc, and back & forth among these cells until finally reaching the cell which actually starts the movie. It tested OK on my Panasonic player, but interestingly actually confused my Sony S7000 player enough to cause it to turn off!!!!

I used PgcEdit to repair the thing by using its Remove Cells feature.

I don't know if latest RI4M & FixVTS work "better" than these early versions, but it's a heck of a test disc jeanl (and a good movie, but perhaps only if you've also read & liked the book).

[blutach]

@laserfan

If you wanna get rid of any stuff left by RipIt4Me (http://www.ripit4me.org/), the easiest way is to use the remove crap function of the Mad Monk's plugin (advanced mode) and then run FixVTS (current domain).

Regards

[Sumster]

Hi JeanL,

Thanks for your reply -- yes, in trial number 2, it deletes the first 5 minutes of the movie (it does not even show up under the unreferenced section). I tried with various software players and it locks up within a few frames. It did the same on my settop box. Shrink ran fine, however.

It is an R1 disc. The only thing with your suggestion, JeanL, is that even if Shrink and a player work fine after PGCedit, the first 5 minutes of the movie would still have been deleted.

I could send you the test files if you would like to play with them -- it's the first time I've really ever had an issue.

Blutach,

Regarding the issue of DVDFab Decrypter vs. RipIt4ME, the fact that the DVDFab rip plays and works fine on both a software player AND a settop box (when burned to a dual-layer DVD) tells me that the rip is actually fine. The issue seems to be with DVD Shrink, and it's the first time that FixVTS hasn't been able to clean up a Sony disc for me.

Just my 2 cents worth.... thanks for your help everyone.


Sumster

[laserfan]

If you wanna get rid of any stuff left by RipIt4Me (http://www.ripit4me.org/), the easiest way is to use the remove crap function of the Mad Monk's plugin (advanced mode) and then run FixVTS (current domain).Ok so I'm confused. I thought that's what FixVTS' "Remove unref. and blank cells" was for? But I still gotta run this plugin within PgcEdit? :confused:

Edit: OK I'm studying "Post-Processing with PgcEdit" in this post (http://forum.digital-digest.com/showpost.php?p=310978&postcount=13) so I guess I've misunderstood that RI4M w/FixVTS is only supposed to get you to a "successful rip" and not a perfectly clean set of files which is what at least one of my players seems to need...

[setarip_old]

@laserfan

Hi!I guess I've misunderstood that RI4M w/FixVTS is only supposed to get you to a "successful rip" and not a perfectly clean set of filesIt's certainly my understanding that using RipIt4Me and FixVTS SHOULD give you a perfectly clean set of files.

Is it possible that you've DE-selected any of the settings in RipIt4Me or FixVTS?

[jeanl]

FixVTS only remove unreferenced cells, and nothing more. If a cell is referenced in the IFOs, then FixVTS won't remove it. If it's referenced and never played, same thing. It's RI4M's job to "de-reference" bogus cells (i.e., cells that are never played, or cells that can be removed safely) so FixVTS can remove them from the VOB file...
Jeanl

[laserfan]

Thanks guys, I ran latest RI4M and FixVTS on "Capote" (Sony title) and got the same 5 or 6 garbage cells remaining up-front in the main title. the "Crap removal" process of Mad Monk's got rid of the extra cells.

I think I'm good with all this, though feeling a bit that the RI4M author maybe would like to know that the process included therein is not strictly complete (my player shuts down!). But I'm likely one-in-a-hundred-thousand with this issue... :p

[setarip_old]

I still believe some of the settings under the "RipIT4Me" "Preferences" have been DE-selected - such as "Remove tiny cells" or "Remove protected cells"...

[blutach]

You could be right setarip_old

AFAIK, RipIt4Me leaves all cells that are played, together with their cell flags and commands intact. This mimics exactly what the original DVD did.

However, a setting to remove all tiny cells (less than 1 second according to the guide), should eliminate them - see section 3.2.2 of the RipIt4Me (http://www.ripit4me.org/) guide.

If the tiny cells are longer than 1 second, I guess they will be left in. But no player should have any trouble playing such a cell.

So some tiny's

Regards

[laserfan]

If the tiny cells are longer than 1 second, I guess they will be left in. But no player should have any trouble playing such a cell.Well FWIW I have all options selected (to get rid of these) and my player still has trouble.

But it appears the "crap cleanup" post-processing via PgcEdit does what I need, thanks.

[sPeziFisH]

hmm, I used RipIt4me to backup 'Underworld Evolution', shrinked to 4,7 GB, everything is fine.
Then I came to the idea to run FixVTS again..
After that processing the folder holds 3,7GB :cool:
A quick view with PowerDVD gives me the impression, that everything is still alright.
Can somebody give a comment on this - maybe it's good to shrink less and run FixVTS afterwards even though you don't know where you end at least but... or is running FixVTS after shrinking still a bad idea?

[blutach]

@sPeziFisH - Run FixVTS before shrinking to get rid of the unreferenced material.

@laserfan - you might also try the new Jump To Menu feature to essentially eliminate tinys before the playback of the title.

Regards