Seek, weird in PowerDVD after ifoupdate

[emilius256]

Hello,
here's again the dumb guy does dumb questions.
This is a little weird thing that happens to me with the anime PAL DVD Video Girl Ai (Episode) opened with powerdvd using the "Playing DVD Files from Hard Disk Drive" and with the burned dvd using DVDDecrypter (image created with imgtool classic 0.90 build4)
I follow the doom9 and trilight guide on how to use the big3 and have perfectly working dvd backup.
My question is the follow, if i play the file in powerdvd after the authoring in Scenarist, the seek using navigational slider works perfectly.
After putting together the copy of original .ifo, .bup, vts_xy_0.vob and the scenarist authored files and proceeding with the ifoupdate step and ifoedit get vts sector, seems i can seek only by chapters point.
For example, i move the slider forward until time 1h 00m and the movi play from the end credits start (but the end credits REAL time is 1h 21m 21s) then move the slider 5m forward and again the begin of end credits, so on until 1h 21m 21s where instead of the end credits i see the begin of the next episode (the real time is 1h 23m 31s).
If i open a vob file directly in powerDVD i can seek with no problem.
Except this little problem i can fast forward with no problem and jump to chapters.
The movie is interlaced and i've encoded interlaced (no prog. scan, no top field first, checked alternative scan) and in ifoupdate i've selcted "Copy Audio and Subpicture Tables" 'cause i've deleted japanese language and italian subtitles but after copying the original .ifo and .bup i can choose between italian and japanese language and this give me disc error when play with my standalone.
I don't know if this is the way to be or i made mistakes but althrough this little problem everything work perfectly.
Sorry for my long post and for my ugly and bad english.
Thanks.

[BinaryBin]

I've ran into the same thing a while back, and only thing that fixes it, is when you do the ifoupdate, you go to Options and check VTS_TMAPTI Table Transfer (Time Map)

so do your normal ifoupdates settings and check VTS_TMAPTI Table Transfer (Time Map) and then you will see that the seeking works, that is only IF the time map actually transfers over, i've Seen it once that it wouldn't transfer over, saying that the time map was to big or something. But when it did transfer over, it would then seek correctly. Give it a try :)

Whatever else that option does to your video, i have no idea, i just know seeking in powerdvd then works like the original.

[quantum]

This is discussed in more detail at the end of this (http://forum.doom9.org/showthread.php?s=&postid=326015#post326015) thread.

I find it unfortunately common that the VTS_TMAPTI table cannot be transferred in ifoupdate. I would guess maybe 50% of the time on the projects I have done. The only workaround I found is to do a hexedit transfer as discussed in the link above.

If this is not done, seeking will be innacurate not only in your software player, but your standalone players as well. This means for instance if you try to jump to a specific time in the movie using your standalone remote, it will not go to the right spot. I find this bad news, so I always do my hexedit trick when necessary.

[emilius256]

thank you guys for your answer.

@BinaryBin this method doesen't work, give me no error but the table wasn't transfered, but because sometimes work will be the first thing i try on the next movie.

@quantum i try with your method and seems to work flawlessly, i use ultraedit too and was a little painful for me too understanding the way paste without shifting. first i calculate how many byte are in the VTS_TMAPTI and the delete it. then paste as usual.

Thank you

[BinaryBin]

The only reason you gotta do that other method is Only if the first method doesn't work, thats why it came up with that, i had on my own come up with a solution that seemed to work for me.

You know in that method quantum talked about in that thread. Well, when you open it in ifoedit and look at the table, and see that size number, you can edit it directly, so all i did was change that number to the same number as in the original ifo, and then i went back to ifoupdate and then it would transfer over the map table, and didn't give the its to big to fit error (this error isn't a popup, its in the actually text thats scrolling, it just says so.) anyways. so thats all its checking is that value, if it not the same or to small, it won't transfer, so changing it to the same as the original and then doing the ifoupdate (making sure you check that transfer table map) it worked perfectly, i didn't have to do all that hex editing stuff thats you guys doing :P maybe somebody else can try that and see if it works for them.

Edit - emilius256 - it should either say transfered successfully or say something else like to big, not Transfered, either says transfered or NOT transfered, are you sure you even checking that option? no Guides ever tell you to check that option, or wtf it even does, and its not ever checked by default, you gotta check it every time you open ifoupdate.



I think this is pretty serious thing, and i have no idea why nobody else talks about it, its not in any guides, no steps have been made to find a better solution for this, nothing, just ignored.

[emilius256]

@BinaryBin i will try what you say in the next backup.
Probably i write a misunderstanding, i mean that your method doesen't work for me at this time but for sure i'll try again and because ifoupdate give me no error probably i made a mistake somwhere.

Thank you

[quantum]

Binary's technique is definitely faster. I hope it works. I'll try it the next time I get the error, which by odds should be in my next backup or two.

I agree Binary that this is a fairly significant hole in the process. I don't know why only a small percentage notice it. I guess if you only watch a movie straight through and never need any navigation it'll never turn up.

[emilius256]

Sorry BinaryBin, can you explain exactly what do you change ?

Thank you

[emilius256]

I guess i finally find.
I've changed the End byte of VTS_VOBU_ADMAP int the authored ifo the same as the original ifo, when i save ifoedit complain about The IFO Endsector does not match the file size but the ifo is saved correctly and now when i do ifoupdate and check to transfer the VTS_TMAPTI table everything's working right.
Thank you all for your help.

[quantum]

It didn't take long for the vts_tmapti problem to rear its ugly head again. I had two vts sets that had the problem in my last backup.

The first one, I couldn't transfer the table because the authored version was so big it would have overwritten the following table in the ifo. So I couldn't use my hexedit trick or binarys technique.

The second ifo had a 'vts_vobu_admap is too large to fit' error. I attempted binarys technique of changing the 'end byte of vts_tmaps table' so both files were consistent, but the error persisted in ifoupdate, so I had to use my hexedit trick.

[emilius256]

you don't have to change 'end byte of vts_tmaps table' but 'End byte of VTS_VOBU_ADMAP'.
At least that's what i did and worked.

[quantum]

Oops, my mistake. I just had another occassion to do this and updated the VTS_VOBU_ADMAP and it worked. Thanks for the tip. It is obviously faster that way.

[BinaryBin]

Yup, it is alot faster ;)
And thank you emilius256 for clearing up on Exactly what to change. :D Now if only this got worked into tools, so this can be fixed automatically, so this time table map can be transfered correctly, it is really important, it causes problems if its not there. Seeking problems, and not only in software, but also on standalones. Most people don't even know that you need that timetable, its not even a default option in ifoupdate.

[Chu]

Originally posted by BinaryBin
Yup, it is alot faster ;)
And thank you emilius256 for clearing up on Exactly what to change. :D Now if only this got worked into tools, so this can be fixed automatically, so this time table map can be transfered correctly, it is really important, it causes problems if its not there. Seeking problems, and not only in software, but also on standalones. Most people don't even know that you need that timetable, its not even a default option in ifoupdate.

Ran into my first DVD with this problem (guess i'm lucky like that), and have a quick question.

Do you change the value of the "End byte of VTS_VOBU_ADMAP" to the last entry on the table listed (in my case, 00003844) or the last entry + 3 bytes? i.e., is it asking for the real end, or the start of the last word?

Is it is the latter option, well, the very last entry is at address 00003844, and 3844+3 = 3847, which is the value listed under "End byte of VTS_VOBU_ADMAP". What happens if I truncate this table in an attempt to get some seeking to work? I noticed that the "number of VOBU's" is not editable, or is this a calculation based on start to end range of the table divided by 4?

Thanks in advance,

-Chu

-Chu

[quantum]

You take the value from "End byte of VTS_VOBU_ADMAP" from the authored ifo and paste it into the ifo that will be changed by ifoupdate.

I've used this technique on about a dozen titles so far and it hasn't failed yet. You may or may not get an error in ifoedit, such as "somethings wrong, endsector doesn't match..." but continue on and it will work.

Always do a ifoedit "get vts sectors" after doing this.

I recently had an odd case where the vts_tmapti table at first appeared to transfer correctly, but then when correcting VTS sectors, I got the "somethings wrong" error that couldn't be fixed. I did this procedure and it fixed the problem.

[killingspree]

hi guys,

"I think this is pretty serious thing, and i have no idea why nobody else talks about it, its not in any guides, no steps have been made to find a better solution for this, nothing, just ignored."

"I agree Binary that this is a fairly significant hole in the process. I don't know why only a small percentage notice it. I guess if you only watch a movie straight through and never need any navigation it'll never turn up."

"Now if only this got worked into tools, so this can be fixed automatically, so this time table map can be transfered correctly, it is really important, it causes problems if its not there. Seeking problems, and not only in software, but also on standalones"

Actually I agree with you, this should be in some way included into the guide. Therefore, I'd suggest that someone volunteers to collect the information into a nice document, adds the links to the respective threads where the information was taken from to the bottom and sends the whole thing to doom9, politely requesting to add this information to the existing guide. I am sure that, if time allows it, doom9 will write the additions. I would do that myself, but do not have sufficient time at my hand right now.

the other option would be, that you guys get together and write that part yourself so that doom9 just has to prooveread it and then can import it into the guide himself. You should definitely contact him about it first though.

steVe
PS: I have encountered this problem myself a few times, but I guess I was lucky, as transfer timetables always worked :rolleyes:

[Abnormal]

Hi,
I have been trying to backup my copy of Animatrix and i keep getting the same VTS_TMAPTI table error with IFOUpdate. I tryed the method BinaryBin suggested with changing the End byte of VTS_VOBU_ADMAP but the DVD would still not seek properly.

I had a look at the other method with a hex editor but i dont quite understand what i need to do. I got to the part on opening the original IFO in a hex editor and went to the 'End byte of VTS_VOBU_ADMAP' address but i dont know where to copy too from this end position.

Oh! I used Maestro Adjusted Cell Method instead of Scenarist

Also i was wondering whether the VTS_TMAPTI table should be transfered on every backup so that it functions as close to the original as posible, or is it just not worth it some times.

Thanks,
Abnormal