The VG Resource

PC - Broderbund, 'Totally Mad' - (late 1990's, 7 CD's)

ok technically not a game, but still entertainment (Mad Magazine)... and this is probably the only place I would expect to find where someone would have experimented with similar types of extractions... considering that Broderbund did make games as well.  Has anyone out there tried to extract data from the related media files?  
Each disk has a set of related files (in 'MEDIA' folder) that obviously work together in some fashion based on prefix... 

MAD.M#  (where # is the disk number, and the largest file, where most content resides)
MAD.MED
MAD.IOB 

There are other smaller files on each disk (3 files for each unique prefix, same extensions).... such as HANGNAIL.M1,HANGNAIL.MED,HANGNAIL.IOB

The M# files begin with a JPEG/JFIF signature, but generally would not be considered that type with any viewer program ... although clearly, the bulk of the data resides in that single file (per disk)... 

Trid reports similar to the following on each MAD.M# file: 

 29.9% (.MPO) Multi-Picture Object bitmap (4500/1/1)
 26.6% (.JPG) JFIF JPEG bitmap (4003/3)
 19.9% (.JPG) JPEG bitmap (3000/1)
 16.6% (.MP3) MP3 audio (ID3 v1.x tag) (2500/1/1)
  6.6% (.MP3) MP3 audio (1000/1)

I tried universal extract, no luck there.. also messed with quickbms (although not familiar), but there's really no matching file type I can determine.. tried to do the brute force job with quickbms, got stuck on testing #48... I also used exiftool, thinking there could be an array of exif data entries, since it has the JFIF signature, which reported the file as JFIF version 1.02... but really nothing significant reported there.

Any ideas or advice, let me know, thanks!

Upload the file samples so we can take a look for you! (Use a foreign file host as I assume the site won't let you upload them here)

Thank you for any assistance! 
Here's a small sample.. although this may not be a significant enough contribution for handling the larger data files properly (which are 500+ MB each).. not sure the file structures will necessarily be consistent:
  
https://1drv.ms/u/s!ApeQyo2q4zBLmjrU5c8bhlduLksq

Note to anyone viewing: The M1 file contains concatenated JPEGs, and the *.MED is the index for it (Don't know that structure, though yet.) The *.IOB file is a zlib compressed file, what the data is I don't know. Regardless, the IOB file can be decompressed with this script (For anyone downloading the game and looking at it):

Thank you for the IOB info... TRID reports the output accordingly: 
100.0% (.PI3) DEGAS hi-res bitmap (2000/1)
I ran your script on another IOB and the report was the same...  This appears to be an Atari file format.  
I've read that DEGAS is an image editor for Atari ST computers; hi-res (640x400)
I downloaded some plugins for irfanview, couldn't get it to display... also tried xnview... also tried a prog called 'Konverter' which takes a long time to load depending on the number of plugins installed... anyway, so far I haven't figured out how to view the Atari file...

UPDATE: Even though the extracted ".dec" file from your script reports as 100% PI3 with Trid, that software report appears to be misleading, and unknown such as you stated (to us at least), since I believe a proper PI3 file should open with one or more of the programs I tried, such as Recoil for Windows...

I've done a bit of work figuring out the .MED file format and pretty sure I can fully uncompress the .IOB file data and and other data files that have the ZLIB_1 tag in them.

The .M1, .M2, etc. files are concatenated and slightly proprietary JPEG files.  The .MED file gives the name of each page and an address noting the CD number and offset into a .M# file.  Useful, but the .M# files can be easily broken down into a single page per file by looking for the $FF $D8 JPEG marker.

I've not figured out how to decompress the proprietary JPEG format.  Based on this Stack Overflow question they used a commercial library from Accusoft.

https://stackoverflow.com/questions/5602...arker-0xb9

My guess is that the JPEG files use arithmetic compression (as opposed to the common and slightly less efficient Huffman compression) for the quantized DCT data.

It is possible some modern JPEG library supports this format.  But it may be that the proprietary version is just different enough that it won't work.  Looking at the DLL's that ship with the product it may be just as easy to figure out how to call them and get them to do the decompression.

I'll try and remember to post I update if I manage to get anything working.