lkVCDimager is based at the original VCDimager by Herbert Valerio Riedel aka 'HvR',
who did a fine job 'figuring' out some frontends which allowes us 'video-freaks' to build custom (S)VCD's.
This project is registred according the GNU General Public License,
and so are all used/rewritten 3th party libraries : libvcd, vcdxml and libxml2.
lkTest, a test program for the library also is registred according this license.
All source codes are OPEN SOURCE and therefore FREE.
lkVCDimager comes as a win32 dynamic library and as 1 or more frontends, the library only works in 3th party software in order to be able to function.
Currently lkVCDimager contains 2 main functions : lkVCDxBuild and lkVCDxRip
lkVCDimager will do exactly the same as the original VCDimager v.0.7.10, but it also supports ISO9660 level-2 directions when one adds custom files and/or directories.
lkVCDxBuild is not intended as some kind of GUI/UI with which you could interactively generate (S)VCD's.
In fact, it acts nearly the same as the original VCDxBuild of 'VCDimager' by HvR, you already must have generated an XML
using the DTD by VCDimager or lkVCDimager and feed that one to lkVCDxBuild.
There are a few (free) good applications around with which you can start authorizing you (S)VCD's, to name one of them :
VCDwizard,
VCDeasy,
TSCV.
The XML created by one of these applications, will then be alright to feed to lkVCDxBuild.
Currently only VCDwizard rel. 2.6.0.0 (and up) supports lkVCDxBuild directly.
While lkVCDxBuild is a frontend of the function lkVCDxBuild in the library lkVCDimager,
all specifications explained in this online reference comply to both versions.
Internally, there is no diferance. The only diferance is the way how both are called.
The frontend is called at the consolewindow (in a win32 dos-box), the function in the library is called via 3th party software
(preferable GUI's).
ISO9660-1, the specification which is most common used, is very restricted.
It only alows filenames using the typical <8>.<3> format. Directories even may not contain an extension, so they are limited to maximum 8characters in width.
The characters allowed are of the ISO646-d characterset (all in uppercase).
The maximum length of a full path should not exceed 255characters and only until 8 directories deep can be gone (this includes the root :
<root\sub1\sub2\sub3\sub4\sub5\sub6\sub7\file.ext>
ISO9660-2 differs from ISO9660-1, in this that it allows "longer" filenames.
In fact, a filename or directory can contain upto 31characters (this is including the dot and the extension of 3chars with filenames).
Although you've still got the limit of maximum 255chars for a complete path.
While VCDimager was restricted to the ISO9660-1 specification, lkVCDimager will be restricted to the ISO9660-2 specification.
Because most OS' are very 'forgiving' with these kind of restrictions at a CD-Rom,
lkVCDimager also supports lowercase chars in custom files/directories only (the restricted (S)VCD directories and their contents
remains using the ISO9660-1 specification, I've done so to keep things 'compliant').
lkVCDimager does have 2 specification validators.
All directories (and their contents), which belongs to the (S)VCD specification will be validated according the ISO9660-1 specification.
All other "custom" directories (and their contents) will be validated according the ISO9660-2 specification.
| (S)VCD restricted folders : | ||
|---|---|---|
| 1) CDDA | 6) MPEGAV | |
| 2) CDI | 7) SEGMENT | |
| 3) EXT | 8) SVCD | |
| 4) KARAOKE | 9) VCD | |
| 5) MPEG2 | ||
While ISO9660-2 is inherited from ISO9660-1, the order of the directories and files are sorted in ascending order at the CD-ROM, using a case-sensitive sort-routine.
This means for example, if you add a folder with the name <.\Sb> and a folder with the name <.\sa>,
the folder <.\Sb> would be written at the disk before the folder <.\sa>, but if you would browse
the disk in for example Explorer (of Windows), it would tell you that <.\sa> is before <.\Sb> -
this while win32 does its own sort-routine at ISO-tracks, which is case-insensitive.