panzi/mediaextract

Extracts media files (AVI, Ogg, Wave, PNG, ...) that are embedded within other files.

mediaextract's Issues

Almost perfect

Thanks for this great tool. It allowed me to extract many textures and sounds from an old game I am trying to remake.

However as the title suggests, it's not perfect yet - there are some textures and sounds in the game, that for some reason are not found by the tool.
Here you can see several textures that I was able to extract.

However the two most used objects of the game seen in this animation, rocks and unids, are not extracted.

The same goes for sounds. Many are there, but not all.

Do you know what could be the reason for this?
I can provide you with further info if needed.

False detect on a stray RIFF chunk

So reflecting the other issue (#1), here is a chunk of binary data which looks like a WAV file, however in the reality there is no such content there. As far as checking in a hex editor, it definitely looks like a WAV header, and even sox tries to play it, detecting an almost 7 hours long content (this also applies to the source of the hexadump below, so it likely contains the problem).

00000000  52 49 46 46 f8 ff ff ff  57 41 56 45 66 6d 74 20  |RIFF....WAVEfmt |
00000010  10 00 00 00 01 00 02 00  44 ac 00 00 10 b1 02 00  |........D.......|
00000020  04 00 10 00 64 61 74 61  d4 ff ff ff 52 49 46 46  |....data....RIFF|
00000030  f8 ff ff ff 43 44 58 41  66 6d 74 20 10 00 00 00  |....CDXAfmt ....|
00000040  00 00 00 00 00 00 58 41  00 00 00 00 00 00 00 00  |......XA........|
00000050  64 61 74 61 d4 ff ff ff  18 00 18 00 50 32 01 00  |data........P2..|
00000060  02 00 02 00 4c 32 01 00  4e e6 40 bb b1 19 bf 44  |[email protected]|
00000070  20 05 93 19 00 00 00 00  00 00 00 00 00 00 00 00  | ...............|

I understand maybe this will just become a "wontfix" depending on what is actually in there (I didn't look in RIFF specs, so don't know), just posted it out of interest.

License?

Looking to package this for the AUR, and couldn't seem to find what license this was released under, could you add a LICENCE file?

Thanks!

XMI support

Hi, this is a cool little tool! Any plans for including support for XMIDI (.xmi)? It's fairly similar to MIDI.

Support flac audio format

Add support to extract flac files embedded in other files.

UTF encoding/decoding is broken

UTF-8 encoding/decoding is definitely broken (-> needs rewrite), other UTF variants need testing.

Files limit

Can't extract full 300mb file at once and need to delete first half with HXD. (ogg files)

Fonts Format Support

Hello, Excellent Program, Just Pretty Missing A Format To Extract Is ::::::: Fonts
TTF OTF PFB ...

extract to... smk

C:\mediaextract-2015-03-13\build-win32>medi
aextract.exe --formats=all Army_Lose.smk
Extracting 0x00000000 ... 0x00333e4c (3.20271 MB) from Army_Lose.smk
Writing 3.20271 MB to .\Army_Lose.smk_00000000.smk
Extracted 1 file of 3.20271 MB size.

Why extract .smk to .smk? I need all files contains. What's wrong?

On winXP 32bit.

Feature request: simplifying output filenames

I often extract from directories containing many data files, each with a single media asset embedded. This is usually a png or jpg image. So in this use case there will only be one output file per source file.

Source files are usually something like:
sourcefilename_some-numbers-here.dat

Currently if I run mediaextract -f png * on a list of these files, I'll see output filenames such as:
sourcefilename_some-numbers-here.dat_00000020.png

It would be very useful to be able to omit the source file extension and the numerical suffix (maybe 2 options there?) from the output filename, giving output such as:
sourcefilename_some-numbers-here.png

This would save a lot of renaming after the conversion!

Possible infinite loop on RIFF content

Hi! Thanks for this useful little program, worked nice, however I had to patch it up a bit. So a bug report:

In the riff.c source, the riff_isfile routine may produce a zero in info->length. This causes the main program becomes stuck in an infinite loop (it doesn't increment the file pointer as far as I understood, this case).

Without giving much in understanding the program in-depth, I patched riff_isfile so it doesn't return TRUE (1) when "end - data" is zero (simply by adding one more condition in there). This worked for me, and feels somewhat appropriate since a zero length data just shouldn't match anything.

I can't quite give a sample to reproduce the bug since I used the program to burn through an entire HDD image (which got its file allocation tables wiped out), and had no much intention trying to isolate this. Hope the location of my patch gives enough clue for a proper fix.

question about offset parameter

Thanks for this perfect program. It's very useful for me.

But many time I get the following error when using the --offset parameter, but I have no idea what this error means.
"The base address or the file offset specified does not have the proper alignment."

For example --offset=127K or --offset=129K give this error where --offset=128K is ok.

Improve Usability

Hi, the tool is nice and now extracts everything I need, but the usability leaves much to be desired.

Most annoying things:

• When specifying an output folder that doesn't exist, perform a check at the start and offer to create the folder instead of throwing an error on every extraction-attempt and having to wait till the file is completely processed.
• Change the default output to something like ./extracted . Having the source folder spammed with thousands of <1kb files by accident can be annoying
• Have a default value for minimum file size (e.g. >1kb for non-text). I think you rarely are looking for very small files and valid images/sounds are rarely that small. Having no minimum just tends to extract tons of useless files. Of course you can set it to 0 via option. I just think the default values should provide a more out-of-the-box experience.
• Ask the user for formats and output dir when no arguments were provided.

Mostly IMHO, but 1. would be very useful.

Is the png.c/png_isfile function really recognize the png file？

I don't think so. the function can't check the chunk block CRC32 code.