Tweet
FAT only supports a maximum file size of 2GB. That is why some burning programs split their images into multiple part images.
I have such an image that consists of 4 parts. It is of '.gi' format (prassio primo DVD format).
It consists of 4 files:
xxxx.gi (few kb's)
xxxx (11).gi (2GB)
xxxx (12).gi (2GB)
xxxx (13).gi (0.2GB)
The only file daemon tools understands is the second one, (11). I was happy when I was able to mount it and I started playing the dvd in media player. However, after 1 hour it crashed. Daemon tools simply cut off the dvd.
Since daemon tools was able to understand the first part I figured that it would be able to understand the other parts if I would concatenate them.
I did that using this command:
copy /b "xxxx (??).gi" xxxx.bin
And indeed, when I mounted this xxxx.bin, daemon tools was indeed able to read the dvd completely.
However, this costs:
- 1 extra human intervention step
- 4,5GB of temporary space
- about 10 minutes on my 7200 RPM harddrive
- This wouldn't even work on FAT32 since the max filesize is 4gigs
It would be superb if daemon tools would start to support this file format without having to concatenate the files manually. I don't think it would be very hard to implement either. Only thing that would have to be changed are some addressing issues. All bytes above 2GB are accessed from the second file and all bytes from the third file are accessed from the 3rd file.
Some suggestions how to let daemon tools know there are multiple parts:
- reverse engineer the first .gi file, it has the info in it (if legal)
- if there is (11) in the file name look for (12);
INSERT INTO `portal_posts_text` VALUES
(13) and so forth
- make it possible to select multiple files and conactenate them internally
- let us make a form of mountable cue sheet manually for the files and daemon-tools could find the filenames of the .gi files to concatenate in there.
I have such an image that consists of 4 parts. It is of '.gi' format (prassio primo DVD format).
It consists of 4 files:
xxxx.gi (few kb's)
xxxx (11).gi (2GB)
xxxx (12).gi (2GB)
xxxx (13).gi (0.2GB)
The only file daemon tools understands is the second one, (11). I was happy when I was able to mount it and I started playing the dvd in media player. However, after 1 hour it crashed. Daemon tools simply cut off the dvd.
Since daemon tools was able to understand the first part I figured that it would be able to understand the other parts if I would concatenate them.
I did that using this command:
copy /b "xxxx (??).gi" xxxx.bin
And indeed, when I mounted this xxxx.bin, daemon tools was indeed able to read the dvd completely.
However, this costs:
- 1 extra human intervention step
- 4,5GB of temporary space
- about 10 minutes on my 7200 RPM harddrive
- This wouldn't even work on FAT32 since the max filesize is 4gigs
It would be superb if daemon tools would start to support this file format without having to concatenate the files manually. I don't think it would be very hard to implement either. Only thing that would have to be changed are some addressing issues. All bytes above 2GB are accessed from the second file and all bytes from the third file are accessed from the 3rd file.
Some suggestions how to let daemon tools know there are multiple parts:
- reverse engineer the first .gi file, it has the info in it (if legal)
- if there is (11) in the file name look for (12);
INSERT INTO `portal_posts_text` VALUES
(13) and so forth
- make it possible to select multiple files and conactenate them internally
- let us make a form of mountable cue sheet manually for the files and daemon-tools could find the filenames of the .gi files to concatenate in there.
Comment