Nitty-gritty technical details for DVD authoring and DVDAfterEdit installation.
The Disc Layout Graph shows how a DVD is laid out physically, by files, and further breaks down the VOB files into their constituent parts. It is shown at the bottom of the main window left pane.
The graph represents all the files in the project proper (spec files). It shows the positions of the .IFO, and Menu and Primary .VOBs.
IFOs are red, menus are green, main vobs are blue. ROM files are grey.
In the Mastering Edition, the graph is derived from the bridge (DVD directory) and includes indicators for the layer break and end of disk (in black). The full width represents the maximum size of the type of disc currently in use.
In non-mastering editions, the graph is derived from the IFO file list and does not include ROM files or layer information, but is otherwise similar.
When an item is selected in the left pane, the storage information for that object is highlighted in the graph (more saturated coloring and the full height of the graph).
A related addition appears in the right pane of the Video Manager (VMG). Under the Video Manager heading in the mastering edition only is an entry for Disc Mastering Info. This shows the diameter of the disc, its capacity, and how much space is available.
When the maximum size of the dual layer disc is exceeded, the text color changes to red and a bold red line appears above the Video Manager heading warning that the maximum size has been exceeded and by how much.
Two additional fields have been added to the cell information in the right pane when a cell is selected. The first shows the distance of that cell from the beginning of the file that contains it. The second shows the cell location relative to the the beginning of the finished disc, and if the disc is dual-layer, whether it is in the layer break range, and if not, how far it is before or after the range. Distances are given in sectors, which are 2048 bytes each.
Please experiment with this new feature and post your comments in the discussion forum.
Regards,
Larry and John
I recently discovered a case where Unix permissions had messed up what I wished to do with a project. For some reason the VIDEO_TS folder itself was marked read-only. (I have no idea how that happened, what with transferring files over the network, copying DVD mounted images to the hard drive, etc.
If such a situation arises, you will not be able to delete or replace any files in the folder, using the import/replace functions, so the operation will quit in the middle with a write permissions error and the VIDEO_TS folder will be left in an intermediate state.
In a future release we will check the permissions of the VIDEO_TS folder and its enclosing folder in addition to the checks now made on the individual files for the warning "Some files are not writable.... etc.", and will not permit the above operations which would fail. In the meantime, please be careful.
If you are currently using an Adaptec SCSI card, even if it has performed flawlessly for you over the years, you should replace it with an ATTO PCI UL3S or UL4S. That is because:
The Format/Copy Dialog has been reworked to make it a bit easier to understand, and expanded to permit user modification of some additional descriptors on the disc, tape, or tape image. As part of these changes, additional application and project preferences were added.
The dialog is now split into five sections, organizing the fields into logical groups. It is hoped that this organization will make it easier for the author to focus on the fields of interest.
Format/Copy
This section shows the source and destination options for the format/copy. This is the only section shown for all selections except the copy from project to tape or disc image.
Copy Protection
For copy to disc image, this section contains only the Copy Generation Management and Macrovision fields, since these are the only copy protection fields that can apply to a disc image. All regions are enabled by Rule.
For copy to tape or tape image, this section also contains the CSS and Output Format choices, plus the region encoding.
Layer Break
The layer break info is shown for both tape and disc, even though it really applies only to tape for replication. The Disc Side field is updated in the Video Manager if necessary.
Directories
This section determines whether or not to include Macintosh ROM Data, and how to construct the ISO, Joliet, and UDF directories. If Macintosh ROM data is not included, any .DS_Store files are excluded.
Descriptors
The Disc Name is derived initially from the enclosing folder name, but may be changed by the author. It determines the name to be used for the replicated disc, and is not restricted to upper case characters as is sometimes enforced by other software or authoring conventions. This field is also used to derive several internal directory fields that normally are never exposed, but may appear in TFDVDEdit logs.
The Tape Label is also derived from the enclosing folder name, and may be changed. This field is written to the ANSI Tape Volume Header, and is restricted to Ascii characters. This is the first record written to DLT, and can be used to identify your DLT later. Many other fields are written automatically to the tape or image, and may be discovered at a later time from the log, including the current date and time the tape or image was created.
The Publisher would normally be your Client, or your Company if you are authoring your own DVD's. This is written to the Publisher field in the directory information.
The Preparer is usually you, the Author. It is pre-filled from the information you gave when you registered TFDVDEdit 3, into your Application Preferences, where you may change it. It will contain the Company Name if you gave one, or if not the User Name. Whatever is in the current Application Preferences is copied into each new project. It is written to the Data Preparer field in the directory information.
In DVDAfterEdit 3, the name of the folder which encloses the VIDEO_TS folder is very important, as is the contents of that folder.
First of all, that name is used to create the project file, and unfortunately the program currently does not distinguish between the same folder names at different levels of the disk hierarchy. This will be fixed in HDAfterEdit, which uses full project files and non-destructive editing.
The enclosing folder name also becomes the name of the DVD Video disc when it is replicated. And all folders and files within this enclosing folder (at the same level as the VIDEO_TS folder) become the ROM data, for disc images as well as replicated DVD's.
If a mistake is made in building a VIDEO_TS folder to a bad place and then it is opened in DVDAfterEdit before moving it to a better place, you should delete the project file to prevent further errors. To do so (See Project Files):
The ISO, Joliet, and UDF directories on a DVD are three way to define the file structure of the ROM data on a DVD.
DVDAfterEdit fully supports all of the DVD Video specification directory and file types, including Macintosh Resource Forks and Unicode. It also gives you full control on the directory types you build, while preserving file naming specification limitations and other spec requirements, and defaulting to reasonable choices to make things easier for you.
This whole subject is made complicated by the way things started with CD's and the limited DOS 8.3 file system, graduated to ISO-9660 file names, was later given the Joliet Extensions, and then finally UDF 1.2 was adopted for DVD ROM content, along with continued support for the earlier formats.
The DVD Video content itself, i.e. the contents of the VIDEO_TS folder, always conforms to DOS 8.3, and the file names themselves are fixed by each file's role in the structure of the DVD. This means that the other formats are not needed unless there is ROM content, except that the DVD spec always requires a UDF directory.
The four choices given to you in the ISO popup are:
Many of the latest operating systems and applications do not use ISO or Joliet, but the DVD Spec requires at least the DVD Video Files (VIDEO_TS.IFO, VTS_1_0.VOB, VTS_1_1.BUP, etc.) be present in the ISO directory. This means you must have at least option 1. If there are no ROM files, or if there are but they all conform to DOS 8.3, option 2 is viable. Files without a suffix do not meet the DOS 8.3 specification.
Full ISO format requires all upper case characters or numbers, no spaces, very limited special characters, and no more than 30 characters in the name. (See the ISO-9660 spec for more details, if you must).
File Names Mangled means that the program will force all file names to legal ISO-9660 names, and eliminate any duplicates that might result. For a Japanese file name (16-bit Unicode), this might result in something like "_________.TXT", which is not very useful. Probably option 1 is a better choice, since the names will be still show up correctly in the UDF directory, described below.
For a given choice, the Format/Copy dialog will show how many files, if any, were eliminated by that choice.
To see what the resulting file names would be for a given ISO choice, make sure that "Log ISO Bridge" is enabled in the preferences, and click the "Log" button in the Format/Copy dialog.
The three choices given to you in the Joliet popup are:
Joliet format permits 64-character file names with lower-case alpha and other relaxed restrictions. It also relaxes the ISO requirement for directory nesting to no more than eight levels. It doesn't hurt to include the Joliet Directory if the names conform. (It only costs a few sectors of disc space). Otherwise None is probably the best choice.
Again, the dialog will show how many files were eliminated by a given choice and you may create and inspect the log. ("Log ISO Bridge" will also enable logging of any Joliet Bridge).
The three choices given to you in the UDF popup are:
Option 1 is there because it makes sense if there is no ROM data. There wouldn't seem to be much point in including ROM files on the disc that can't be accessed, or in not including them in UDF but including them in ISO or Joliet, but someone might think of a legitimate reason.
UDF permits 127 16-bit Unicode characters, or 254 8-bit Unicode characters. If any character in any name is not in the list of legal 8-bit Unicode characters, all names will be represented in 16-bit Unicode.
If not all names are legal in their entirety, you may choose to mangle them (reduce them to legal names). Perhaps a better choice, particularly if this results in eliminating any duplicates, is to reexamine the file names.
As before, you may create and inspect the log to assist you with fixing the names.
[inline:1=center,Adaptec drive system profile]
We do not officially support Adaptec SCSI cards! If they work, fine. If not, you must get an ATTO card to run Pre-Mastering. But if you wish to try Adaptec, the driver version numbers shown above, in the System Profiler, are the recommended versions for best operation of DLT drives. Be aware that an Adaptec card may work for a while, and encounter new problems later.
The ATTO ExpressPCIPlus driver version should be 2.0.4 or 2.1.2.
» Click Here to Download ATTO ExpressPCI Plus Driver Installer v2.1.2 (SIT format, 107 KB)
Later drivers fail badly with some Operating System versions. The Adaptec versions are the versions normally shipped with the OS. ATTO driver version 2.0.4 is shipped with the OS, and if you installed version 3.1.0 from the web site by mistake, you may replace it with 2.1.2 from the web site. (It's listed under OS 10.2.8).
To get to the System Profiler, select "About This Mac" in the Apple Menu and then select "More Info...".
These driver problems can't be entirely blamed on the SCSI card vendors. Apple keeps trying to fix errors in their SCSI card support and introducing still more errors.
If you encounter hardware errors with a particular OS and driver version, you may have to experiment with other combinations to fix the problem. Be sure to post your problem in the Beta Forum to get help. DVDAfterEdit Pre-Mastering may encounter hardware/driver errors when other applications do not.
Here is a complete procedure for writing DLT masters. There are plenty of unnecessary steps here, intended to catch human error and bugs which have long since been fixed, but it's what I do, and it works every time. Hope you find it useful ! - Ian
It may also be worth deleting the preferences for your project before trying this procedure, too. It will be in
/root volume/Users/user name/Library/Preferences
with a name of the form
com.tfdvd.DVDAfterEdit.project.xxxx.plist
where xxxx is the enclosing folder name for each VIDEO_TS folder
In DVD Spec commands, there are only 8 registers available to the author, if he or she is using an abstraction-layer authoring system such as DVD Studio Pro, or 16 if there is no abstraction layer, such as in Creator or Scenarist, or if you replace the abstraction layer and author from scratch in DVDAfterEdit.
To make better use of these registers, each register can be split up into individual "fields" to be treated individually. Since registers contain 16 bits, there could be 16 individual bit fields that each kept track of a single on/off state. (Binary bits are either on or off). Or it could be split up into 4 fields of 4 bits each. (It is quite often useful to do this).
Bit fields don't translate to decimal values very well. For example, the rightmost (lowest) bit in a register has a value of 1. The highest bit has a value of 32768. The next highest bit has a value of 16384. (Notice these are all powers of 2). Combining or doing arithmetic on groups of these bits in decimal would be very tedious and confusing. But good news! Once you understand hexadecimal, it becomes much easier.
Hexadecimal is base 16 arithmetic. This means that each digit in hex has 16 possible values, instead of 10 in decimal or 2 in binary. This is very good for three reasons:
These facts all combine to make it easy to work in hexadecimal, as you will discover as you continue reading this document. If you plan to do extensive DVD Spec "scripting", it would be a good idea to buy an inexpensive hex calculator.
In hexadecimal notation, each digit is commonly referred to as a "nibble". The possible nibble values are:
[inline:1=center,hexadecimal nibble values]
The DVD Spec uses registers that are 16 bits long. This equates to four nibbles of four bits each. This means a register can hold a value from 0 to FFFF in hex, which is 65,535 in decimal.
Typically in the DVD Spec, all values are positive numbers only. But almost all microprocessors, including all of those in DVD players, use "two's complement" arithmetic, which essentially allows you to think of these values as negative values if you wish. In two's complement arithmetic -1 is represented as $FFFF (we will use $ to represent hexadecimal numbers from here on out).
As an exercise let us add one to 9999 (decimal). We add one to the lowest 9, and get 10. We write down the zero and carry the one. We add the carry to the next digit, also 9, and get a similar result. When we finish we have 10000.
Now let us add one to $FFFF. We add one to the lowest F and get $10 (16). We write down the zero and carry the one, etc. When we are finished we have $10000. But only four nibbles fit in our register, so the last carry is thrown away, and the result is zero.
So you can see that in two's complement arithmetic, -1 + 1 still equals zero. For scripting purposes, we don't really need to know much more than that, except that it would is possible to store a negative value in a register, and our good old hex calculator will tell us what that value should be, if we need to know.
The DVD Spec uses the Boolean operators "and", "or", and "exclusive or". These operators only make sense using binary notation. But hex is a good way to organize your binary data into manageable chunks. With a little practice it is very quick to translate a hex number into binary by drawing out the nibbles on a piece of scratch paper, thus:
$06FF: 0000 0110 1111 1111 $1ABC: 0001 1010 1011 1100
(Please refer to the table, above, to get each nibble of the 16-bit hexadecimal number).
Then you can isolate the piece of the GPRM or SPRM you are interested in by drawing a long vertical line between the appropriate bits (counting from the right as bit 0), and apply the Boolean logic to it. (I'll explain Boolean logic in a moment).
For example, button numbers are stored in SPRM's and referenced starting with button number one having a value of 1024, or $0400. Button two is $0800, button 3 $0C00, etc.
So my example of button number one would be drawn thus:
0000 01|00 0000 0000
(On paper you would make the vertical bar taller.) If you draw all of the possible buttons out you will see that the 10 bits to the right of the button number are always zero. This means that scripting can keep track of a button number and still have 10 more bits to play with in the same GPRM!
This concept is extremely powerful, and is what permits complicated navigation with only 16 GPRM's. Essentially, GPRM's are very expensive, and commands are cheap since you can have up to 128 of them in each PGC, and you can have tons of PGC's.
Boolean Logic
The three Boolean operators used in DVD Spec commands are "and", "or", and "exclusive or". These operands are usually represented by the operators "&", "|", and "^".
Boolean operators are applied one bit at a time to two operands, and each bit in an operand is compared to the same bit in the other operand. The result of the compare is stored in the destination operand. (In DVD commands, the destination is always a GPRM, or a "temporary value" (never stored) in an if statement).
"and": If both bits are true (1), the resulting bit is true.
"or": If either bit is true, the resulting bit is true.
"exclusive or": If either bit is true, but not both, the resulting bit is true.
Some examples:
$0010 & $0011 = $0010 $0011 & $1000 = $0000 $0001 | $0010 = $0011 $0000 | $abcd = $abcd $8000 ^ $8000 = $0000 $e000 ^ $4000 = $a000
etc.
An abstraction layer example
Following is an abstraction layer example from DVDSP 1.5, which was written before DVDSP 2.0 was shipped. Although the abstraction layers for the two products are different, the principles are the same.
This example was also written before DVDAfterEdit supported the hexadecimal preference for commands. Here in this update we will show the hexadecimal. For those who have read the previous version of this document, you will see that this makes the code much easier to follow.
If you look at a typical DVDSP 1.5 project, at the Video Title Set Menus, you will see that the first 20 lines of PGC 2 are always identical.
1: Set r15 = r8 2: Set r15 ^= $E000 3: if r15 & $8000 then GoTo Line 7 4: Set r14 = r8 5: Set r14 &= 7 6: Set Stream Audio r14 7: if r15 & $4000 then GoTo Line 13 8: Set r14 = r8 9: Set r14 /= 8 10: Set r14 &= 63 11: if r14 != $3F then Set r14 |= 64 12: Set Stream Subpic r14 13: if r15 & $2000 then GoTo Line 18 14: Set r14 = r8 15: Set r14 /= 512 16: Set r14 &= 15 17: Set Stream Angle r14 18: Set r8 = 0 19: Set r15 = r13 20: if r15 == 0 then Link Resume
This code is using a single GPRM, r8, to hold three flag bits and three values. Before reading any further, notice that $E000 has three bits on, $8000 has one of those same bits on, $4000 has another, and $2000 has another. Gee, there must be a method to this madness!
Here is a picture of the bits as they are arranged in register 8:
[inline:2=center,bits as they are arranged in register 8]
Now to describe each command line and what it does:
From here on out, the individual menus "do their thing", usually testing r13 for particular values to go to particular places.
Notice that the abstraction layer coding isn't particularly efficient in the number of instructions used, but is very efficient in its use of the bits in general parameters.
For example, the abstraction layer designer could have reversed the meaning of the three high-order bits in register 8, which would have saved the instructions which had to move the bits to another register and invert them in order to test each bit. But this sort of optimization is unimportant in typical navigation, since commands themselves execute in microseconds and there is room for 128 of them in each PGC. It is only when we actually jump to other domains and areas that navigation slows down.
Actual and possible layer breaks are now shown in the left pane, and the layer break may be chosen with a contextual or Edit menu function. They are shown by one of four icons (or none) immediately to the left of the disclosure triangle.
A blue 45-degree arrow on an entry means that the entry itself is not a legal layer break, but contains lower-level items in the hierarchy that are.
A blue right-arrow means that an entry itself is a legal layer break.
A red 45-degree arrow means that the actual layer break occurs in a lower-level item, but is not this item.
A red right-arrow means that this is the layer break entry. Since the layer break is a physical location, and PGCs are a logical construct, more than one PGC (within the same VTS) may show the same layer break.
In addition to layer breaks on cells in the VTS area as before, layer breaks are now also permitted to be in menu cells, or on a VTS IFO file. For an IFO file, the arrow will point to the VTS entry itself. These latter choices are likely to be good ones, since they will more likely occur during navigation and not playing of video, except for motion menus.
There is an entry in the Edit Menu to hide and show the layer break arrows, so they won't be distracting during normal editing.
If a project does not have a legal layer break, you may insert a cell and make it the layer break in one step, using the Insert Layer Break function on a Nav Pack.
You may still choose the layer break from the Format/Copy window instead of the main window if you wish.
TFDVDEdit automatically creates a project file for each VIDEO_TS folder (project) that you open.
It is important to understand how the project preference files work. The preference files are always found at /root volume/Users/user name/Library/Preferences.
The file with the name "com.tfdvd.TFDVDEdit 3.plist" is the application preference file. This file contains the serial number validation info, the application preferences as shown in the preferences dialog, and additional parameters such as the current paths for file dialogs. You should not delete this file unless your preferences get corrupted. If you delete it it will be regenerated, but you will have to enter your application serial number again.
Additional files will be created with the names: "com.tfdvd.TFDVDEdit 3.project.xxxx", where xxxx is the enclosing folder name for each VIDEO_TS folder that you open. Such files are always created even if you never save the project. Moving the project has no effect on finding the project file. Unfortunately, multiple enclosing folders with the same name will battle for who gets to have a project file, each time you open one of them.
You may open any preference file with the Property List Editor if you wish to see what is inside it. This utility is provided as part of the Mac OS X XCode tools. It may also be opened with any XML editor. TextEdit will show you the raw XML code.
Currently all of the fields in the preference file pertain to the layer break. We intend to add more fields for other purposes later. (After 3.0 release).