[DVDnav-discuss] Is it possible to work around `PTT search table too small.`?
gnosygnu
gnosygnu at gmail.com
Wed Apr 24 06:18:26 CEST 2013
Hi Paul.
I'm not a DVD expert, and I don't know anything about dvdbackup. However, I
can provide one wild guess as well as some detail that may point you in the
right direction. Keep in mind that it's been two years or so since I last
looked at this, so my details may be incorrect / loosely worded / overly
convoluted. Anyone else feel free to correct me.
TL;DR: As a wild guess (which is likely wrong), you can try:
(gdb) p vts_ptt_srpt->nr_of_srpts = 23
I'm going to guess there are 23 "chapters" in the title, and if you update
the number correctly, the rest of the process may complete.
-------------------------------------------------------
Basis for the wild guess :
(which even as the wild guess may be incorrect,
the details may hopefully be somewhat correct,
though unfortunately they'll still be very long)
-------------------------------------------------------
* vts_ptt_srpt->nr_of_srpts is generally (but not always) # of chapters in
a title.
** It is "offset 2: number of chapters (PTTs)" in the following link
http://dvd.sourceforge.net/dvdinfo/ifo_vmg.html
** I believe it is being read by ifofile->vmgi_mat->tt_srpt in ifo_read.c
* info_length is closely related
** it is derived from "offset 4: end address (last byte of last VTS_PTT)"
in http://dvd.sourceforge.net/dvdinfo/ifo_vts.html#ptt
** the corresponding line of code is
info_length = tt_srpt->last_byte + 1 - TT_SRPT_SIZE
where tt_srpt->last_byte is "offset 4" and TT_SRPT_SIZE is defined as 8
As you've realized by now, these numbers should be somewhat close. If the
nr_of_srpts is greater than the actual info_length, then the program will
end up reading data from unknown places. Hence the assertion above.
So, based on this background:
* nr_of_srpts is falsely reporting 99 # of chapters (99 sounds like a
"made-up" number)
* The more important # is info_length. This is based on how the data is
actually stored.
To get the correct number of chapters (nr_of_srpts), let's start off by
reversing the formula above. So,
* last_byte = info_length - 1 + TT_SRPT_SIZE
* last_byte = 96 - 1 + 8
* last_byte = 103
103 is the number that should be at "offset 4: end address (last byte of
last VTS_PTT)". Or "tt_srpt->last_byte". You'll notice it's the "last_byte
= 103" above.
Now to get the number of chapters, I do the following. Note that I subtract
an extra 4 to account for the 4 bytes of "offset 8: offset to PTT for title
1" (this is a slightly complicated explanation)
* num_chapters = (tt_srpt->last_byte + 1 - TT_SRPT_SIZE -
4_BYTES_TO_SKIP_OFFSET_8) / NUM_BYTES_IN_AN_INTEGER
* num_chapters = (103 + 1 - 8 - 4) / 4
* num_chapters = 23
So the real number for nr_of_srpts should be 23, not 99.
FWIW: I've tested this calculation now with two generic region 1 DVDs:
Spider-Man 2; Battlestar Galactica Disc 1.
That said, these DVDs tend to mess things up in many places, so you may
find you're stopped by something else.
Anyway, hope this helps and best of luck.
On Mon, Apr 22, 2013 at 5:23 PM, Paul Menzel <
paulepanter at users.sourceforge.net> wrote:
> Dear DVD experts,
>
>
> with the True Grit DVD (region 2) I am seeing the following error
> message using `dvdbackup -M …`.
>
> libdvdread: PTT search table too small.
>
> Others also seem to have that problem [1].
>
> That is exactly the DVD from which this code originates from to fix a
> segmentation fault [2]. The code was added in revision 1232.
>
> Author: erik
> Date: Sat Aug 13 17:28:45 2011 +0000
>
> Fix crash when PTT is too short
>
> The PTT that is allocated and read is smaller than what gets
> referenced.
> The data is byte-swapped in place which results in writes to
> memory
> locations outside the allocated region. Region 1 True Grit is
> an
> example of this.
>
> Derived from a patch submitted by John Stebbins. Thanks!
>
> diff --git a/libdvdread/src/ifo_read.c b/libdvdread/src/ifo_read.c
> index 5f7ffa9..15bade5 100644
> --- a/libdvdread/src/ifo_read.c
> +++ b/libdvdread/src/ifo_read.c
> @@ -1184,6 +1184,10 @@ int ifoRead_VTS_PTT_SRPT(ifo_handle_t
> *ifofile) {
> goto fail;
> }
>
> + if(vts_ptt_srpt->nr_of_srpts > info_length / sizeof(*data)) {
> + fprintf(stderr, "libdvdread: PTT search table too small.\n");
> + goto fail;
> + }
> for(i = 0; i < vts_ptt_srpt->nr_of_srpts; i++) {
> B2N_32(data[i]);
> /* assert(data[i] + sizeof(ptt_info_t) <=
> vts_ptt_srpt->last_byte + 1);
>
> I wonder if it is possible to come up with a workaround, which does not
> stop. Looking at the variables with GDB, in this case there is
>
> (gdb) p info_length
> $1 = 96
> (gdb) p sizeof(*data)
> $2 = 4
> (gdb) p *vts_ptt_srpt
> $3 = {nr_of_srpts = 99, zero_1 = 0, last_byte = 103, title = 0x0,
> ttu_offset = 0x0}
>
> Unfortunately even after reading `libdvdnav/doc/dvd_structures` I have
> no idea what the PTT (part of title track) actually does. Clueless as I
> am, I did
>
> (gdb) p vts_ptt_srpt->nr_of_srpts = 24
> $4 = 24
>
> but that resulted in a wrong image, as the folder the DVD was copied to
> had a size greater than 19 GB, which is not right. I saw a lot of
> »Filling up blocks(?)« messages – which I cannot find in the source, as
> I used German local and do not have access to the system right now.
>
> Additionally, I do not even now, what I am missing with this error?
>
>
> Thanks,
>
> Paul
>
>
> [1]
> http://forum.ubuntuusers.de/topic/digitalisierung-einer-dvd-mittels-dvdbackup-sc/#post-4772402
> [2]
> http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2011-July/001407.html
>
> _______________________________________________
> DVDnav-discuss mailing list
> DVDnav-discuss at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
>
More information about the DVDnav-discuss
mailing list