[ivan]

Maybe you should add support for paragon's compressed image format (cdi). Paragon CDI is the native cd image format used by for the Paragon CD-ROM Emulator program to create backup copies of cds. The special thing about Paragon CDI is that it supports data compression.

I'm not competent in cd image file formats, but I think that Paragon CDI is different from DiskJuggler's CDI, because when I try to load a Paragon CDI in DT the only thing I get is an error message.

Paragon homepage: http://www.cdrom-emulator.com/

I hope this helps you.

[Benji99]

I also eagerly wait the compression iso feature, but I have a slightly different advantage in mind.

Basically I plan in the near future to rip every single cd I own to the harddrives (those are anything from application cds, to games, training cds etc...).

Basically I have a few problems (albeit very minor problems) with this, one of which was already mentioned, I would be wasting space, and If I rar them, I have to decompress them before I use them, which would suck.

THe other issues I have is that since I like to use the ripping program which I think is best for the job, clone, BW, cdrwin, DJ, etc... I will use several programs, and this will result in various different formats which will look unclean, but at the same time, clone creates 4 files, cdrwin 2, etc..., It would be nice to have a universal "container" compressed or compressed where 4 files would look as 1 on the file system, and they will use the same extension regardless of the actual image format used within.

I know my problems are very minor, but I'm anal retentive, and would love to see compression added to daemon tools, which would solve practically all my problems, hell I'd even be able to burn the cds directly without decompressing first...

Benji99

[shawn8888]

I am wondering if it is difficult to apply this feature. (Support Zip or Rar)
Could it be possible in the next version?

[The_Morph]

One of the biggest problems will be that several of the mentioned compression algos are not documented nor available for free. I stumbled across an almost perfect replacement for rar recently: sqx. sqx is a freely available compression/decompression library from Rainer Nausedat (www.sqx-archiver.org) which comes will full source code and a complete SDK. This will surely ease up things a lot. Even more, SQX comes with support for archive encryption, so no need to create another plugin. (And just for the records, I'm not connected to SQX in any way, I just like it almost as much as my beloved winrar )

If I remember correctly, the daemon drives have 512 kbytes cache by default so why not compressing chunks of 214 blocks. Data is read sequentially in most cases anyway so there wouldn't be a large overhead but better compression in return. Why 214 blocks? A cd sector can have 2448 bytes maximum size, depending on the image format ofcourse.
A raw sector has 2352 bytes, plus 96 bytes subchannel data makes 2448 bytes. As we have to take care about the maximum allowed cache size, we will have to stick to 214 blocks per chunk or use variable chunksizes depending on the current image data.

Audio CD support will be a bit more difficult, at least for lossy compressors like mp3. Anyone who reads the lame discussion boards will know why.

I haven't had a look at FLAC and other lossless compressors, so I don't know how accurate chunk compression will be with these compressors, however, audio compression may turn out to be a real beast.

By the way, great idea with the image plugin system. Is any documentation about it available? I don't have much time these days

[zagnut]

this whole compressed iso concept is interesting... i've considered it in several respects, particularly with regard to:

1) transparency to the user
2) responsibility of this product's developers and this particular product
3) demand
4) comparable solutions/alternative approaches

with respect to .1, existing formats (rar, gzip, bz2);
none of them have really been designed with random access in mind, so the compression is always quite block-oriented (ie, files are compressed as whole chunks for a size that is often chosen for how it affects compresability -- ex, by file, by set of files, or by some maximum size premited by memory)... while this helps get a good ratio, it doesn't make for quick/easy decompression (random access and speed)... so, just like with Zipfolders, i fear existing formats will tend to require long waits before access... this is less of an issue on pimped-out boxes, but not everyone has 2gb ram and 4ghz idling... interestingly, flac HAS been designed with decompression speed/random access in mind AND it gets a better ratio than winrar on a 700mb audio cd image i tried the other day... i wonder... has anyone tried compressing data with flac? i might have to...

with respect to .2, i think it's hard to justify the suggestion that dtools be responsible for compression (or at least the definition of a compressed format -- tho if another app/group did, it might be worth simple SUPPORTING it... but no such format exists, and surely competition would quickly negate the effort spent as the first...)... also, if anything was definied it would have to be opensource in nature since surely dtools can't be turned into a conversion app -- that's something for another program to do... dtools just deals with images... any broaders scope would turn this nice small util into a 4bm fatso... the open nature of such a scep would lead to competing implimentations and less advantage.

with respect to .3 the demand is there, and growing... ppl are getting sick of discs, and want a good way to virtualize them. this - lack of compression - is becoming representative of a glass ceiling for many disc junkies; i mean: even 100gb drives fill up quickly when files are 600+mb each...

with respect to .4, as was noted there ARE file-based solution like ntfs, and just because it doesn't work for one person with software raid, doesn't mean it's not a relatively effective solution for others... i mean, even zipfolders would work if you could cope with the lag (in fact, who's to say the under-performing ntfs compression wasn't the lesser of evils... it could be high-compression and lots of lag... i suspect ms considered that issue thoroughly...). so there are options... mp3 is an option, and we've already been told mp3+cue is not an option... i think that's an appropriate choce... if dtools has to support every encoding, why not uuencode? that get's rediculous... rediculous to develop OR support.


all in all i think it's a little too lofty a goal for a utility... this is very generic stuff we're talking about... stuff that shouldn't even come into play in a utility that is really just simplifying the "now" of comuting (discs, copy protections, etc...)... why should it be trying to apply an "architecture"... it seems like the wrong place... an os with compressed files alla ntfs is the place for that... anywhere there is a platform there is a place for that... my question to the developers is this: is dtools a platform?

my opinion is that dtools is presicely where it ought to be... making virtual cd emulation fun... i think the benefit of it comes from the specific nature of it... support only for images to mount...

that said, i feel justified in suggesting in a previous post that dtools might consider supporting flac as an "image to mount"... it may not serve the data side, but it has the [growing] potention to serve to audio side....

[fantc]

Has anyone yet considered the linux compressed iso file image system that KNOPPIX uses?

http://www.knoppix.net/docs/index.php/cloop
http://developer.linuxtag.net/knoppi..._2.01-1.tar.gz

The file format consists of a header, an index table for block translation and of n blocks compressed with zlib at a given original block size.
That seems very simple, and it's easy to create compressed iso's from non compressed iso's.

Where can I get information, how these DLLs in the [image] directory of the daemon tools work? What interfaces must they provide?
I do not have many experiences in c/c++ programming (I mostly deal with java). Any help is appreciated.

[Development]

Mentioned DLLs currently handle only images without comression. their task is handle information specific to individual formats.
Compression handling is planned to do in other modules (Plugins\Files)
This design is under development.

[fantc]

Hello,

thanks for the information. That's what I thought, but I would like to know more about the interfaces of those DLLs, to try a bit with other proprietary iso images. I also would like to know more about how to write a plugin. Can you provide such information?

[fantc]

I mean a plugin that can be placed in Plugins\Files, or is that not possible at the moment?

[LocutusofBorg]

it is possible. You should write an email to me
locutus@daemon-tools.cc

(only experienced developers please)