[Request] .aif file support

[tony971]

Another disc compression format request, but (in my opinion) superior to #1964 #2128 or #2584 in that it compresses better than those formats while still focusing on preservation, and can be used for both CDs and DVDs. The tool itself is pretty extensive, even having documentation for the PS2 memory card format.

https://github.com/claunia/DiscImageChef

Edit: They've re-branded as Aaru

https://github.com/aaru-dps/Aaru/

[mirh]

Putting aside I hardly can think of shortcomings in CHD to begin with, that looks way more like a tool than a format. There doesn't seem to be documentation anywhere, except the (?)code itself.
For devs not to become stupid with inventing the wheel, a neat C library like libchdr would be required imo.

[lightningterror]

Maybe a meta issue should be created instead to put all these format issues in.

[mirh]

The thought also came to my mind.
But then I figured out every format is a standalone case, different from others.
Also, for the love of god, I'd hope there shouldn't be any more suggestions?

[tony971]

This request was mostly born from the comment thread here.

https://www.reddit.com/r/emulation/comments/ac10d2/comment/ed4l3dx

Between the redump people thinking it was the more appropriate option and beating chd in compression, it makes a strong case.

[i30817]

The redump people are often quite thoughtless. CHD is used by mame dumps (they're already using it on ps1), already has iso and dvd iso support (a iso is just part of a cue with one track in MODE1/2048).

CHD is also well specified with useful features that i've never seen on other formats like internal 'DATA SHA1' that applies to all of that data, not single files and is compression level independent (thus it's a truly unique signature/foreign key) and ability to attach metadata (and count it as part of the internal data for the 'DATA SHA1' or not), and already has a independent library implementation used by various projects.

I'm not anxious for this train of good things to get derailed for a NIH made in C#.

Redump should get it's house sorted and put the 'Data SHA1' in their dats, you do not need to convert dumps to calculate that, other formats (like that one) could standardize on it and the entry shared on the DAT, and would allow a standardization of a foreign key that cuts across console for a complete unique id for a chd rom.

RA is currently full of per platform hacks that are both a burden (different file structures, different serial parsers, different approaches) and incomplete (serial parsers can't differentiate a game from a hack, nor can cue checksums or potentially other kinds of 'single file' checksums when the dump is not a single file).

Then again i'm criticizing redump, but TOSEC manages to be even worse with ill thought 'standards'. For instance did you know their dreamcast set has the gdi (cue equivalent) files mostly equal (and thus the smallest file has the same checksum). At least when i floated the need of a cue salt to redump (because of 'same game, different platform') they accepted the necessity and hadn't already shot themselves in the foot, even if they did nothing yet.

The only thing i want chd to have now is support for more weird disc formats that are dump standards (like gamecube/wii 'isos') and libchd to make it easy to stream, mount and random access the images so incompetent projects don't have a excuse to uncompress the whole disc on /tmp.

[claunia]

Hi all,

There are some shortcomings, of maybe not the highest importance, to CHD, one that may be interesting to PS2 emulation, like storing the wobble data. dicformat (that's the name, dicf is just the extension hehe) can store that, and any other information we want.

As for the "data hash" that CHD has, dicformat also has it.

Besides, the MAME team themselves think their format has some shortcomings, and they have asked me to port dicformat to C to study it.
And I have started that work in https://github.com/discimagechef/libdicformat unfinished because time has not allowed me.

And it's not a thing of not invented here syndrome, the reason I created the format is because there is not a single format that is able to store all kind of media (for know implemented support for optical discs, magnetic disks, flash media and streaming digital tapes -DDS, LTO, et al) with all the information about the media (including, but not limited to, CD TOC, CD-R PMA, DVD PFI and DMI, LTO memory, etc), the dumping process (drives used, resume listing for partial dumps) plus metadata (full metadata about the contents, several hashes, etc), in an expandable, opensource, compressed, deduplicates, and archival (with copy on write and checksums features) features.

I welcome any usage, help to finish the C library and suggestions of changes and enhancements.
Same way, I welcome you to not like it and not want to use it.
I needed a format able to do all of that, so I created it.

P.S.: dicformat v2 will have better support for big disks (>200Gb) and copy protections (including twin sectors).

[mirh]

Cool.
Though, while I don't really know the specific details of MIPS playstations DRM, I believe there's a point after which obsessively extra info is just waste.

If MAME and redump folks have finally come together, I thank god the heaven may finally see one last once and for all format.. but I hope we won't have to store the spin of atoms if the dvd reader can just barely read the normal tracks.

[claunia]

@mirh

I believe there's a point after which obsessively extra info is just waste
I believe the same, but as I'm not a dumping group I don't require anybody to store that extra data, just provide the facility for anybody to store as much, or as less, as they want 🤷‍♀️

How the format is done a field that's empty (like DMI in most DVDs) takes a neligible amount of bytes, and a field that is not stored, takes 0.

[tony971]

DiscImageChef is now Aaru. I've updated the issue accordingly.

[lightningterror]

Closing as trivial, we support other formats which are enough.