Are 99 chapters the max allowed when authoring a DVD?

[atropos]

Or is there a way around this limitation?

Thanx,
atropos

[Lord of the Discs]

They are not, they may be the max for some entry-level authoring-software.
The standard alows 99 chapters (programms or PTTs) per PGC, 999 PGCs
per VTS and 99 VTSs per DVD.

The way around is using more powerfull software.

[atropos]

I have already authored my movie files which are now ready for burning. Is it possible to add the extra chapter points without having to demux again, and is IfoEdit or any other software capable of doing this?

Thanx,
atropos

[Lord of the Discs]

I don´t know of any software which can add chapters to already
authored project, looks like you´ll have to re-author it.

[duanbingnan]

DVD+R/+RW 99 chapters in one title, upper 508 chapters in one disc.
DVD-R/-RW(VR) 99 chapters in one title, upper 999 chapters in one disc
DVD-R/-RW(Video) No limitation by DVD format

Is this right? or can someone tell me the chapter limitation for each format of DVD,thanx in advance!

[blutach]

A DVD may have a maximum of 99 VTSs and a maximum number of titles of 99. Each title may have up to 999 program chains (PGCs) but is usually just 1. A PGC may have up to 99 programs, each of which can be a chapter, however max number of chapters is 999 (eg a title with 999 PGCs, each one being a chapter). A one-sequential PGC may only have 99 chapters max.

A program is made up of cells, which are comprised by their Vob ID (1-32767) and Cell ID numbers (1-255). Max number of cells per program is 255.

There is nothing at all relevant to the type of optical media used.

Hope this helps.

Regards

[Alex_ander]

Originally Posted by atropos

I have already authored my movie files which are now ready for burning. Is it possible to add the extra chapter points without having to demux again...

It is possible with DVDRemake.

1.Split cells in preview window (right-click + 'split here').
2.Add 'Program' attributes to proper new cells in Programs tab ('Insert program'). This enables navigation by previous/next buttons.
3.If necessary (e.g. for linking from menu) register new programs as chapters in VTS Titles. Some command editing may be necessary in this case due to changed chapter numbers.

Something like this can be done with combination of VOBBlanker + PGCEdit, but with less comfort.

[blutach]

@Alex_ander

I would hope atropos has found the solution in almost 5 years

But for the record, this can also be done with VobBlanker pretty much on its own (it handles up to 32 splits, IIRC).

Regards

[Alex_ander]

Originally Posted by blutach

A DVD may have a maximum of 99 VTSs and a maximum number of titles of 99.

I have a funny question of 2 parts.
a) Is this maximum number of titles for DVD or for VMG titles?
b) (related) Is it absolutely necessary to have all VTS titles registered as VMG titles as well?

As for a), I can't find anything inside vmg ifo tables pointing at whole volume properties. E.g. video attributes are just for vmg menu VOB (if there is), etc.

I've been always sure that the answer to b) is 'true'. But recently, while assembling something from different parts, forgot to register an extra VTS title in VMG map, since that title was only addressed from inside the VTS. And it appeared to work (at least on PC). There's also no visible problem with navigation commands, looks like VTS titles can be even indirectly linked from VMG PGCs using VTS menu (in case at least 1 title per VTS is registered in VMG, there's information in VMG ifo's about the # of VTS's and starting sectors for each VTS).
Is this 'legal' or can there be problems coming from the standard VMachine properties? Of course, there's no practical reason to do so intentionally (e.g. to override # of VMG titles limit), just curious. Thanks.

[r0lZ]

I think DVD titles and VMG titles are exactly the same thing. The titles reside always in the VTS domains, but a global table of title (VMG_TT_SRPT, that assigns the title number to each title) is stored in the VMG. When a command calls a title from the First-Play PGC or the VMGM, it has to call the global title number, and when the player executes the command, it looks in the VMG_TT_SRPT table to find in which VTS the title is located. (VTS_TTN is a different thing: it's the title number within the VTS. When a command in a VTS or VTSM domain calls a title, it can access only the titles residing in the same VTS, and calls it by its VTS_TTN.)

The global number of titles in the DVD cannot exceed 99 (probably because most standalone players can only display 2 digits in their led display.) That's what the DVD-Video standard says. However, we have had a discussion here at D9 about the possibility to define a title in a VTS that is not referenced in the VMG_TT_SRPT table. IIRC, according to mpucoder, each VTS must have AT LEAST one title referenced in the VMG, but they can (perhaps?) have additional titles that are not referenced. Of course, that titles have no associated title numbers, and that might cause some players to crash or behave strangely when they try to display the missing title number. It is also impossible to jump directly from the VMG to that title, as you noticed. But the conclusion of the discussion was that those titles are possible, but probably very dangerous. I have seen that only once, in an ARccOS protected DVD, but since that DVD has been butchered by Sony, it's not at all a proof that it's legal! The fact that it works (especially if you test only with software players) is not a proof neither. In fact, I'm still wondering if that is legal or not. Anyway, I have modified PgcEdit to warn the user and fill the missing entries in the VMG_TT_SRPT table whenever possible. Of course, if there are more than 99 titles, I cannot make them all referenced.

[EDIT] Here is the original thread: Always need a VMG title number for a TTN?
Note also that another, related question has also been discussed: is it possible to assign two (or more) VMG title numbers to the same VTS_TTN? Here also, it's technically possible (simply by duplicating an entry in VMG_TT_SRPT) but probably illegal.

[Alex_ander]

@r0lZ
Thanks for your attention to my question. After reading your comments and that older discussion I seem to understand the matter clearer (especially wanted to know how different standalones would react). Looks like the main problem may come from wrong SPRM4 readings: if only used for VMG title # indication, it's almost safe (at worst it would show on display the default #1 VMG title or maybe the last accessed of the registered ones). If a particular device or a software player also uses those readings for title access or (with any device) resuming playback from saved position, it fails.

[r0lZ]

Right, but I guess that GPRM4 is never used directly in a DVD containing "unnamed titles" (to adopt the terminology of the other thread) as it's too risky. The problem is therefore only related to the way the player reacts to the absence of title number. As demonstrated by the tests in the other thread, each player can react differently.

I'm not sure the player has to know the title number to be able to resume to that title, and that has not been tested. IMO, that's not a problem, as the player records probably only the VTS, PGC, cell and position within the cell as the resume point.

[Alex_ander]

I thought the numbers for resuming playback are taken from SPRMs and since VTS# is not stored there, I supposed that it could be derived from global title number (using VMG title map). So should the VTS # be stored externally in a player (in an extra register)?

[r0lZ]

I suppose so. At least, it's how the PgcEdit trace works: it remembers the PGC and cell number. (A real player should also remember the exact position within the cell.)

Take in mind that storing the Title number is not sufficient, as if it's a not-one_sequential title, there is no way to know in which PGC of the Title the resume point is. Furthermore, the player has also to know the cell and the exact position within the cell, and that is not possible with the SPRMs neither. (Of course, if the resume point has been set by a CallSS command, the position within the cell is always the beginning of the cell, but it's not true when the resume point has been set after a call to a menu via the remote: in that case, the resume point is the point where the playback of the title has been interrupted.)

[mpucoder]

To answer another part of your question

Originally Posted by Alex_ander

I can't find anything inside vmg ifo tables pointing at whole volume properties. E.g. video attributes are just for vmg menu VOB (if there is), etc.

The VMG_VTS_ATRT table contains copies of each VTS's attributes. Is this what you are looking for?

As for the TT_SRPT, it serves 2 purposes. Obviously without an entry for a title that title can not be directly accessed from VMG. That much is clear and safe enough. However DVD players also consult this table to determine the title number for the display, and it is here that unpredictable events can happen. The player may display a close match, nothing, or hang up trying to resolve the value. That all depends on the defensive programming skill of the firmware programmer.

The requirement of at least one entry per VTS is to not only allow access to the VTS from VMG, but also most burning programs check this table and modify it as necessary when allocating the files. Having unreferenced files upsets them tremendously.

How a player saves information for resume, whether invoked from CallSS or the remote, varies with the firmware. If I were writing the firmware I would save the context (remote) or create an appropriate context (CallSS) much the same as interrupts do in operating systems. The SPRM's are not the limit of storage in firmware, they only serve to facilitate programming the virtual machine.

[blutach]

Originally Posted by mpucoder

How a player saves information for resume, whether invoked from CallSS or the remote, varies with the firmware. If I were writing the firmware I would save the context (remote) or create an appropriate context (CallSS) much the same as interrupts do in operating systems. The SPRM's are not the limit of storage in firmware, they only serve to facilitate programming the virtual machine.

This is very interesting info, as it has been bugging me for some time how a player can find a point mid cell. I suspected it saves VOBU number and consults the VOBU_ADMAP table in addition to the relevant SPRMs.

Regards