UNECM with stdin input

[hiker13526]

I modified unecm to accept input from stdin. For pakkiso, here's how the process usually goes for unpacking:
read .7z from disk -> 7za extracts -> write .ecm file to disk -> read .ecm file from disk -> unecm decodes -> write .bin file to disk

Using stdin:
read .7z from disk -> 7za extracts -> unecm decodes -> write .bin to disk

This requires somewhere around half the amount of data transferred to and from the hard drive meaning your hard drive should last longer. It's also a tiny bit faster, maybe 3-5 seconds. The program also now outputs execution time, is backwards compatible with v1.0, and I've improved the debug messages.



Here's how to call it:

Code: Select all

7za e -so input.7z | unecm - output.bin

Download link: http://www.mediafire.com/?i12nyjjdnwa

[Nexy]

Nice, should speed stuff up. Hopefully you liked the ideas I had for that GUI version (should work with cli too enough for you to make it. Check out the version Themabus made too which has some extra removal stuff. Maybe it's possible to combine the 2, while still retaining backwards compatibility.

[themabus]

yeah, basically i made ECMa for Dreamcast because of extensive use of padding in GD layout.
but turned out it can also outperform ECM on PSX XA sector encoding rather well
likely cause of this could be some bug in sector analyzing algorithm.
though i haven't looked through it's code myself, since i'd use ECMa instead
those are two things that could be possible to optimize in ECM

edit:
for example try encoding SLPS-00113, it'll crawl from 19% on, apparently something goes wrong there

[hiker13526]

Is the source for ECMa or your (themabus) version of ECMa130 available?

[themabus]

i could send you pascal part without assembler routines, if you want to
it should be possible to link it with CloneCD's ElbyECC.dll instead
but it's really rather simple:
- mode of each sector is determined
- each element (sync, address, subheader, etc.) compared with pregenerated
- those matching removed
so what's wrong with ECM, i think, since it has support of many formats: .cdi, nrg, mdf? - well at least some of those
it might be that on certain data layouts it would get confused and would try to analyze data too much
possibly trying to determine whether given sector belongs to any of those
anyway, that's only thing that comes to my mind without looking at code,
since basis is just a simple comparison and there are no faster/slower sectors per se
except for ECC part but that hardly influence anything
and PSX would actually have less of those than regular CDs

[hiker13526]

i could send you pascal part without assembler routines, if you want to
it should be possible to link it with CloneCD's ElbyECC.dll instead
but it's really rather simple:
- mode of each sector is determined
- each element (sync, address, subheader, etc.) compared with pregenerated
- those matching removed
so what's wrong with ECM, i think, since it has support of many formats: .cdi, nrg, mdf? - well at least some of those
it might be that on certain data layouts it would get confused and would try to analyze data too much
possibly trying to determine whether given sector belongs to any of those
anyway, that's only thing that comes to my mind without looking at code,
since basis is just a simple comparison and there are no faster/slower sectors per se
except for ECC part but that hardly influence anything
and PSX would actually have less of those than regular CDs

Is your program open source? Is ECMa?

[themabus]

no, it's not open source, hiker13526


*locking this topic until issue with spambots is resolved*
themabus @2011.12.10