Announcement

Collapse
No announcement yet.

some kind of compressed images support

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Talking about compressing audio tracks, and the impossibility to recognize mp3-linked cue files... Why not try to implement the ogg format? It is under the GPL licence, and better in quality than mp3...

    As I use daemon tools to mount CD32 isos in UAE this would save a LOT of space as these disks typically consist of 10mB of data and audio tracks...

    Comment


    • #32
      There is another compression method that you can use LZMA its not the fastest compression, but its is more flexible. Its also has quick decompression. http://www.7-zip.org/

      FROM THE SDK SECTION (RIPED)

      LZMA is default and general compression method of 7z format in 7-Zip program. LZMA provides high compression ratio and very fast decompression, so it is very suitable for embedded applications. For example, it can be used for ROM compressing.

      LZMA SDK includes:

      File to file LZMA compressing program (lzma.exe) with source code
      ANSI-C compatible source code for LZMA decompressing
      That LZMA decompression code was ported from original C++ sources to C. Also it was simplified and optimized for code size. But it is fully compatible with LZMA from 7-Zip.

      LZMA Decompression features:

      Decompressing speed:
      8-12 MB/s on 1000 MHz P3 or K7.
      500-1000 KB/s on 100 MHz ARM, MIPS, PowerPC or other simple RISC CPU.
      Small memory requirements for decompressing: 8-32 KB
      Small code size for decompressing: 2-8 KB (depending from speed optimizations)
      LZMA decoder uses only integer operations and can be implemented in any modern 32-bit CPU (or on 16-bit CPU with some conditions).

      LZMA SDK is released under the terms of the GNU LGPL. LZMA SDK also can be available under a proprietary license for those who cannot use the GNU LGPL in their code. To request such proprietary license or any additional consultations, write to support@7-zip.org.

      If you use or plan to use LZMA SDK, please write about it to support@7-zip.org.

      Comment


      • #33
        Originally Posted by desdinova
        Talking about compressing audio tracks, and the impossibility to recognize mp3-linked cue files... Why not try to implement the ogg format? It is under the GPL licence, and better in quality than mp3...
        Yeah, this is kind of what I thought this subject was about, heh. I'd like to see a way for DT to deal with CUE files that link to non-WAV audio files (APE, FLAC, etc). I burn a lot of my audio CD's to APE/CUE sets and save them on my HD and it'd be convenient to be able to mount them with DT whenever I want to play them (etc). =)

        Comment


        • #34
          Windows XP - Compressed Folder

          What I was thinking of:

          Why doesn't Daemon Tools support the windows Compressed Folder feature.
          I mean it's build in the XP OS and even my mom uses it to send a bunch of files to her friends.

          It does solve the problem of direct block access, because (if I'm correct) the OS will take care of that.

          So wouldn't this be the easy first step for supporting compression after a year of discussions about this subject?

          Comment


          • #35
            zisofs sources can help...

            Don't make what is already made ;p)



            The zisofs filesystem is an extension to the ISO9660 filesystem that allows files, on a file-by-file basis, to be stored compressed and decompressed in real time. The zisofs filesystem is supported by recent versions of Linux (2.4.14 or later). Legacy systems can still read uncompressed files. zisofs-tools contains the tools necessary to create such a compressed ISO9660 filesystem and to read compressed files on a legacy system.

            Compare the best free open source Software Development Software at SourceForge. Free, secure and fast Software Development Software downloads from the largest Open Source applications and software directory


            "mkzftree will not compress files that end up larger when compressed"

            We can also imagine to create a better compression FS, imagine a system where each file is extracted in memory with a different plugin... the one where the compression was the best... i think its what 7-zip actually does...

            There are also fs used in Firmwares, but it's made for linux file system only i think : CramFS and SquashFS (better compression) but i dunno exactly differences, maybe zlib / bzip2
            Save environment, use D-Tools :p)

            Comment


            • #36
              Another alredy made cd compression tool/format is those two that cdrmooby uses http://mooby.psxfanatics.com/. It's a plugin used for PS1 emulation software so it is already tested. It's opensource under GPL.

              Comment


              • #37
                How about just mount a ZIP/RAR/7z/etc. archive?

                Comment


                • #38
                  I've been reading and all this sounds interesting. Here is a crazy idea that probably wouldn't work.

                  Would it be possible to implement a stackable plugin system. The first layer would be a file system plugin that handles the actual reading of the needed file. A normal plugin would read real files, but a zip,rar,etc plugin would read files from inside that 'file system'. Next the format plugin would decode the data accordingly, whether it is a ccd or a cue image.

                  For the compressed file, certain information could help speed up access time. For each block of original data, the byte and bit position in the compressed file and the offset of the decompressed data needs to be known. The reason for the bit position is that the compressed codes may be 12 bits or something of that nature, so knowing that a code begins at byte 5 bit 4 is needed. Also, since a code may represent multiple bytes, knowing the offset of the current code to the next block is important. For example, if a code decompresses to three bytes, the first being byte 2046, then the 2048 position would be two bytes away in the decompressed data.

                  What could happen is, when a compressed image is first mounted, a temporary buffer would be used to decompress the selected files on the run. During this process, the above information could be extracted and the code tables could be rebuilt. A cache could be created on the disk containing this information.

                  Comment


                  • #39
                    So how is it looking with this, will the next daemon-tools support some form of compressed images or can we get a development kit to add our own plugins for it?

                    Comment


                    • #40
                      This is a little off the topic of what you guys are going for but today I noticed a feature in Power Producer 3 that surprised me. They have a Defragmenter for use on CD RW's They claim that by more efficient packing of data on the disk you can get a big gain in storage capacity! This is in the "Burn" portion of the video editor.

                      I haven't tried it yet to see if it actually does what it claims because I misplaced my only RW CD :roll:

                      I don't know if you guys have seen this or not, however it's something new to me. Defragmenting a RW CD to store more video on it!

                      Comment


                      • #41
                        If it's simply defragmenting as on a hard drive, it won't give you more than 700MB (on a 700MB medium, of course).

                        However, if you've been using the disc a lot, writing small files, deleting some of them, then creating new ones, the CD-RW could in a way become fragmented, and you could free up the overhead memory by defragmenting. That wouldn't be anything else than defragmenting a hard drive.

                        Just an assumption on my part, however
                        "I was inappropriately blunt, wasn't I? Sorry, I do that a lot."

                        Comment


                        • #42
                          what about adding an application to create index-table file for premade RAR, ZIP, etc. compressed ISO files, and implement in DT reading those archives using the index table for block-like access ?

                          P.S. sorry for my bad english, hope you got the idea

                          Comment


                          • #43
                            PLEASE read through this thread first, you'll see why compressing images is a waste of CPU time in almost every case.
                            "I was inappropriately blunt, wasn't I? Sorry, I do that a lot."

                            Comment


                            • #44
                              Originally Posted by NetSoerfer
                              PLEASE read through this thread first, you'll see why compressing images is a waste of CPU time in almost every case.
                              I did! And i don't agree with you. There are a lot of times when compressing images is very usefull. Please, don't put your thoughts in other peoples minds

                              Comment


                              • #45
                                Originally Posted by RainyShadow
                                Originally Posted by NetSoerfer
                                PLEASE read through this thread first, you'll see why compressing images is a waste of CPU time in almost every case.
                                I did! And i don't agree with you. There are a lot of times when compressing images is very usefull. Please, don't put your thoughts in other peoples minds
                                I agree...

                                I understand when ppl start out doing sth for a particular purpose,
                                the investment sometimes become somewhat emotional

                                actually, if dt is going far, it shouldn't limit itself to gamers

                                today ppl store large amount of data in various formats for reasons far beyond anybody's dreams
                                I work in the financial software industry, clients store gigs of text (or at least, compressible in other sense) files,
                                which apparently could use some compression

                                take for example a 20M text file that contains a lota digits,tabs, comma... (price quotes)
                                this could comfortably compressed to 5% of the original

                                CPU is a hell lot faster than hard drive in this sense.

                                Comment

                                Working...
                                X