Page 4 of 12 FirstFirst ... 23456 ... LastLast
Showing results 31 to 40 of 118

Thread: some kind of compressed images support

  1. #31

    Default

    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...

  2. #32

    Default

    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.

  3. #33

    Default

    Quote 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). =)

  4. #34
    New User
    Join Date
    01.06.2004
    Posts
    1

    Default 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?

  5. #35

    Default zisofs sources can help...

    Don't make what is already made ;p)

    http://www.kernel.org/pub/linux/utils/fs/zisofs/

    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.

    http://freshmeat.net/projects/zisofs-tools/

    "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)

  6. #36

    Default

    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.

  7. #37
    New User
    Join Date
    27.11.2004
    Posts
    5

    Default

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

  8. #38

    Default

    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.

  9. #39

    Default

    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?

  10. #40

    Default

    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!

Page 4 of 12 FirstFirst ... 23456 ... LastLast

Tags for this Thread

Bookmarks

Posting Rules

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •