Open spanned files and drives

As of IsoBuster 5.2 it is possible to open spanned files (and drives).
This means that if you have two or more files (or drives) that are part of one consecutive file (or one virtual drive), you can instruct IsoBuster to open all files/drives and treat them as one.
It's as if the files/drives are concatenated.  Simply seperate the files/drives with the '|' character.

Opening a spanned file/drive is done [1] on the command line (like you open any image file) or via breadcrumb control commands [2] @open: or [3] @cmdl:
Or via an *.imlst file, which is a text file with one file/drive per line

For instance, open two generic image files that together form one image file.

[1] isobuster.exe "c:\image file 1.dsk|c:\image file 2.dsk"
[2] @open:c:\image file 1.dsk|c:\image file 2.dsk
[3] @cmdl:"c:\image file 1.dsk|c:\image file 2.dsk"

It is also possible to open Physical Drives, like you would open image files.
The entire drive is then treated as a file, and IsoBuster's image file parsing simply assumes it's a file.
Note: Normally, if you want to access a drive, it is always best to select the mounted drive and go through IsoBuster's normal drive recognition, in other words use: /d:, for instance /d:2 (to select physical drive 2)

[1] isobuster.exe \\.\PhysicalDrive2 is same as isobuster.exe \d:2 but the former parses the drive like an image file, the latter selects mounted drive 2 (Different logic inside IsoBuster, different dealing with buffer alignment etc. etc.)
[2] @open:\\.\\PhysicalDrive2 (Opens the drive like an image file)
[3] @cmdl:\\.\\PhysicalDrive2 (Opens the drive like an image file) vs @cmdl:/d:2 (Selects the drive Inside IsoBuster)

And so it is also possible to open multiple spanned drives via the same mechanism.  PS. spanned drives can be created with IsoBuster.
Assume you cloned a 2TB drive (1) to two other 1TB drives (2 and 3 (in that order)), because you didn't have a target drive big enough to fit 2TB, then you can open the two drives as one via this mechanism

[1] isobuster.exe "\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"
[2] @open:\\.\\PhysicalDrive2|\\.\\PhysicalDrive3
[3] @cmdl:"\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"

It is also perfectly possible to combine Logical Drives, Physical Drives, Image files and Virtual files.  Examples:

[1] isobuster.exe "c:\first_part.dsk|\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"
[1] isobuster.exe "\\*\virtual:512:0xff|c:\first_part.dsk|\\.\\PhysicalDrive2|\\.\\PhysicalDrive3"
[1] isobuster.exe "\\.\\PhysicalDrive2|c:\second_part.dsk|\\.\\PhysicalDrive3"
[1] isobuster.exe "\\.\\PhysicalDrive2|c:\second_part.dsk|\\.\\f:"

This mechanism is mainly intended for generic files or image files that don't implictly link to other files.
For instance, it does not make sense to do [1] isobuster.exe "c:cd.cue|c:\cd.iso:" because the CUE file contains the name of the file(s) that need to be loaded.
So, in this case, the second part of the path is ignored, since that data comes from the CUE itself.

Also note that all files/drives on the path are seen and treated as one combined file, so only the first file's header (if any) will be seen as a header and only the last file's footer (if any) will be seen as a footer.
The rest is just the body part in the middle. Except:

IsoBuster's managed image files (*.ibp / *.ibq) always come in pairs (or more files if the ibq is split into multiple files).
If you open the IBP file with IsoBuster, IsoBuster also automatically opens the IBQ file(s).  This is based on identical file names and ibp vs ibq extensions.
You can overload this functionality by providing the IBQ file(s) on the command line (or via @open: or @cmdl: or in an *.imlst file)

For instance, @open:c\managed.ibp will implicitly open c:\managed.ibq as well.
However, assume the ibq was renamed (for whatever reason), then you can open it this way:
[2] @open:c:\managed.ibp|c:\renamed.ibq or
[3] @cmdl:c:\managed.ibp|c:\subfolder\renamed.bin and if the ibq was split into multiple files:
[2] @open:c:\managed.ibp|c:\renamed_part1.ibq|c:\renamed_part.i2|c:\renamed_part.i2|c:\renamed_part3.bin|c:\renamed_part.part4

A similar mechanism exists for managed clones.  A managed clone is basically a managed image file, but the IBQ part is a Physical Drive rather than a file.
If you want to overload the Physical Drive signature that is stored in the IBP file then you can provide the drive name on the command line:

[2] @open:c:\managed.ibp|\\.\\PhysicalDrive3 or, if spanned over multiple drives:
[2] @open:c:\managed.ibp|\\.\\PhysicalDrive3|\\.\\PhysicalDrive4|\\.\\PhysicalDrive5 or if part of it is also stored in a file:
[2] @open:c:\managed.ibp|\\.\\PhysicalDrive3|\\.\\PhysicalDrive4|\\.\\PhysicalDrive5|c:\last_part_in_file.dsk etc. (the sky is the limit when it comes to combinations)

From IsoBuster 5.3 onwards it is also possible to use Virtual Files

Virtual files don't really exist, they are fake files with a certain size and a certain content. 
The syntax is: \\*\FileName:(-)Size:Pattern
- FileName can be any name and must contain at least one character.  It can have a file extension, for instance *.dsk (which would help with proper detection of the image file in case it's the first file)
- Size must be present and is the number of bytes.  It can be decimal or hexadecimal (in which case it needs to start with 0x or end with h).  If Size is negative, for instance -512, reads in that part of the file will fail with an error.
- Pattern is a BYTE value and is optional.  Default 0x00 is used but you can specify any value, for instance 0xFF etc.

From IsoBuster 5.4 onwards it is also possible to select a range inside a file, starting from a certain offset

The syntax is: \\#\(Offset,Range)c:\path\filename.ext
Offset and Range are in bytes.  This way it is possible to target an embedded file or stitch together a virtual file made up from fragments of one or more files.

From IsoBuster 5.5 onwards it is also possible to select a target file inside a *.zip file

The syntax is: \\#\zip(target)c:\path\filename.zip
Target supports wildcards.  For instance:
\\#\zip(*.cue)c:\path\cue+iso-image.zip

From IsoBuster 5.5 onwards it is also possible to help IsoBuster detect *.gz or *.bz2 files that don't have the proper extension (*.gz or *.bz2)

If the file doesn't have an extension that helps IsoBuster detect the compression, you can use the proper prefix to let IsoBuster know
For instance:
\\#\gz()c:\path\gzip-compressed.bin
\\#\bz2()c:\path\bzip-compressed.bin

From IsoBuster 5.5 onwards it is also possible to use Image files in a multi-filename, to be treated like normal files.

The syntax is: \\#\img(*Offset,BlockSize,Size*)c:\path\filename.ext
Offset, BlockSize and Size are in bytes, and they are optional. Preferably let IsoBuster detect these values by itself.
Size is determined by the Image File format but that can be overruled by this value.
See the Github content for more information and why this is useful.

As an alternative for providing all files / drives on the command line it is also possible to put them in an *.IMLST file that can be loaded just like any other image file.  This way you can manage file/drive combinations easily in files that can be double clicked or dragged onto IsoBuster.  In a way an *.imlst file is a shortcut to an image file or a combination of image files.  An *.imlst file is a simple text file that contains a file/drive on each line.  It uses the same logic as explained above.  More on Github.