One thing I think that needs to be defined is that there's a difference between systems: ones with and without filesystems.
Ones with filesystems can be much easier, as you kind of have direct contact with the binary data. ZEROLIGHT is correct in saying that one has to define what the binary data means in its context. In this case, whether the binary data is of model vertices, sound samples, or graphic pixels.
Ones without filesystems (ie. ROMs) may be harder, and is probably different. Generally, if a ROM has no filesystem, no identifiable "header" exists, but rather a bunch of tables that point to the data. I believe it's more so reading in tables and getting the properly pointed data (ie. palette + graphics data) in order to create an "extraction".
So, generalizing the idea of writing "ripping tools" is a broad subject: it's a matter of limiting to what you're trying to rip (ie. models or sprites). This of course, may not be accurate; I thought I'd offer up my ideas. though.
Ones with filesystems can be much easier, as you kind of have direct contact with the binary data. ZEROLIGHT is correct in saying that one has to define what the binary data means in its context. In this case, whether the binary data is of model vertices, sound samples, or graphic pixels.
Ones without filesystems (ie. ROMs) may be harder, and is probably different. Generally, if a ROM has no filesystem, no identifiable "header" exists, but rather a bunch of tables that point to the data. I believe it's more so reading in tables and getting the properly pointed data (ie. palette + graphics data) in order to create an "extraction".
So, generalizing the idea of writing "ripping tools" is a broad subject: it's a matter of limiting to what you're trying to rip (ie. models or sprites). This of course, may not be accurate; I thought I'd offer up my ideas. though.