[Development]

File access plugins will work independetnly from image plugins - they will not know what is ISO, CUE etc. They will handle only pure access to blocks inside file. Please also not that most likely all these compression plugins will be written as system drives (*.sys) - no Win32 API can be used. During image access no switch from Ring0 to Ring3 will be allowed.

[PixelaseR]

Originally Posted by VeNoM386

File access plugins will work independetnly from image plugins - they will not know what is ISO, CUE etc. They will handle only pure access to blocks inside file. Please also not that most likely all these compression plugins will be written as system drives (*.sys) - no Win32 API can be used. During image access no switch from Ring0 to Ring3 will be allowed.

Actually, on 2nd thought, I shouldn't be talking about conversion with D-Tools...lol...my bad

I was actually talking about the converter...bleah....two different programs.

I'd like to help with the plugins...but it looks like I am gonna be lost with the fact that I have no idea what Ring0 & 3 is...lol....off I go to do some research...

[xrmb]

The protected mode offers 4 different 'privilege
levels' (ranging from 0..3, aka ring0..ring3). Userland applications
are usually executed in ring3. The kernel on the other hand is executed
in the most privileged mode, ring0.

damn, I learned all that in schools a view years ago, but never used it again... stupid c++, but at least some guys here still know how the system works, no its not the start menu I'm talkin' about

[Development]

I will try to make design as simple as possible to reduce number of kernel code. All this will need some work and testing. The main limitation is 9x OS - on 2000/XP it is practicaly possible to avoid kernel code at all (at some performance hit maybe, but i don't think it matters at all as anyway performance will be lost during decompression).

[PixelaseR]

Originally Posted by xrmb

The protected mode offers 4 different 'privilege
levels' (ranging from 0..3, aka ring0..ring3). Userland applications
are usually executed in ring3. The kernel on the other hand is executed
in the most privileged mode, ring0.

damn, I learned all that in schools a view years ago, but never used it again... stupid c++, but at least some guys here still know how the system works, no its not the start menu I'm talkin' about

Actually....now that you mention it...I do remember having learnt about privileges when I took Windows Programming. I just didn't know they were called "ring". :P Actually, in reality, I haven't touched C/C++ for a long time since for some reason, everyone went for Java all of a sudden. I just started picking C/C++ along with C# back up about 2 months ago....sigh....industry transformation can be devastating....

Now....as for not switching from ring3 to ring0, you mean not using any Windows kernel code but completely "rewrite" the entire ASM code to emulate communication of DVD drives as well as decompression? I believe that would be somewhat very complicated and may takes a long time to optimize wouldn't it?

[PixelaseR]

Originally Posted by VeNoM386

I will try to make design as simple as possible to reduce number of kernel code. All this will need some work and testing. The main limitation is 9x OS - on 2000/XP it is practicaly possible to avoid kernel code at all (at some performance hit maybe, but i don't think it matters at all as anyway performance will be lost during decompression).

Regarding performance hit.....maybe after the code is done, minor code optimization can be done to pull it back up a little bit. I certainly don't think the performance hit would be that great.

[Development]

It can be done in C (not ASM) but it is complex task indeed - experience in writing drivers needed.

[CeeJay]

Xrmb : Could you do test with my favorite compressors too ?
7-zip - http://www.7-zip.org/ - For superb compression
LZOP - http://www.lzop.org/ - For superb speed
(The other datacompression libraries by Markus Oberhumer might also be worth a look)

Both are opensource.

Also note that while the g-zip rutine in 7-zip is about 10% more efficient that G-zip itself the really interesting format is it's own 7z format.
The only problem I can see with it is that it's hard finding the perfect settings for your specific file with so many options available.

0=BCJ2 1=LZMA 2=LZMA 3=LZMA b0:1 b0s1:2 b0s2:3 1d=25 2d=20 3d=20 1mf=bt4b 2mf=bt2 3mf=bt2 seems to work really good

Also you are only compression ISO images, try also to compress CloneCD and Alcohol 120% images , because while it's true that gamecontent can't always be compressed that well , copy-protection data like custom subsectors and etc can be compressed REALLY well.

I did some tests on a CloneCD image a few years back when I first suggested that Daemon should support compressed images and the .sub was compressed down to something like 8% of the original size

BTW they told me I was nuts and that there would be no gain from it since games were compressed already and it would never happen and if they were ever going to support compressed images they would make their own compression algorithm that would be so much better than anything else seen before.

Ofcourse they said something along the same lines when I suggested the analog audio feature and look ! It's in daemon now *g*

I suspect that audio CD's can be compressed to something like 50% of the original size ..
FLAC is a very good codec for that (since it's lossless and backed by Xiph.org)
http://flac.sourceforge.net/

It is ofcourse also opensource.

And while we are on the subject of custom format plugins consider a mp3/ogg vorbis -> audioCD plugin.
I also suggested this years ago - It's intent was to make it possible to hear the music YOU wanted in games that otherwise didn't support custom music and loaded its own music from an audio CD.
I think the developers response back then was that it was completely unnecessary because you could just burn the files to a CD and use it instead *g*

[Jaime]

The amount of compression always depends on the data entrophy level. Entrophy can be assimilated to the concept of disorder (in the sense of lack of unicity);
so compression reduces the entrophy level, reduces the disorder.

Audio data is not as disordered as you may think, in fact, if you take a mono wave file containing music or voice (without silence);
the compression level that can be achieved will be very low. Losless audio compressors capitalize mainly on the concept of 'joint stereo', i.e. in the differences between the channels, so the results will depend on the kind of music/audio data that is processed.

Typical results can vary betwen 45-80% of the original size, more towards the higher values for pop/rock music. If you want to achieve good ratios there's no other way than using lossy compression formats (mp3/mp4/aac/...).

But in my oppinion this is irrelevant, most people will desist on using compression when they see that compressing their game CDs almost gets them no savings at all. The interesting thing is that implementing a flexible plug-in architecture for data processing will open a new range of possibilities, that are good for but not limited to compression; data encryption is a very interesting field that can open new markets for this software.

Following with the previous reasonement, one of Daemon Tools' strong points is the ability to filter data coming from CD/DVD drives, so why not make this feature expandable so data decryption (or other kind of things) can be performed in real-time from physical drives?.

I would suggest to take a look at the BestCrypt's development kit that can be found at http://www.jetico.com, BestCrypt has a kernel mode API and plug-in system.

[LocutusofBorg]

a very good idea, after all new plugin method will provide us with many new concepts and advantages, that I'm sure about