Sounds very similar to how you could use QuickPar.  Basically, just like QuickPar you have to create the recovery data ahead of time (before the disc goes bad).  You also have to store this recovery file (they call it an "error correction file") somewhere safe so that you can use it down the road.

(Gonna read through and see if I understand how they're doing this, apologies if I repeat what you may have said.)

There are differences in how they break down the media (if I understand their page correctly) for recovery.  The default for dvdisaster is redundancy of about 15% or so.  Basically, they're treating the disc as multiple recovery sets.  Using the default settings, each recovery set is 223 sectors (223*2048 bytes) with a 15% redundancy (32 sectors).  The block size is 2048 bytes which exactly matches the physical size of CD/DVD media blocks.

However, the 223 blocks are not taken from a contiguous swath of the disc.  Instead, they "are selected so that they are evenly distributed over the medium surface".  I'm estimating that there would be around 10,200 "sets" of 223 blocks on a 4GB DVD.   

Assume that blocks on the media are numbered sequentially as you spiral out from the middle (in from the outside?) and that there are 10,200 sectors (2048 bytes) on the media..  The 1st of the 223 blocks in the first set would be block #1 on the media.  The 2nd of the 223 blocks would be block #10201 on the media.  The 3rd block would be #20401 on the media.  The second set of 223 blocks would use block numbers [2, 10202, 20403, ...].   (That's a bit of assumption on my part in my attempt to translate "evenly distributed" without looking at the actual code.  I'm assuming that they didn't do anything fancy and just picked sequentially.)

Basically, they're trading off between security and speed.  A reed-solomon matrix of 2048 byte blocks with only 223 source blocks and 32 recovery blocks is probably very fast to calculate.  (I am not a math wizard.)  As long as there isn't more then 15% damage to any *one* set of 223 data blocks, you can recover the 223 blocks in that set.  But if one of the 223 data block sets is damaged beyond 15% it can't pull information from another set of 223 data blocks.  So each of the 10,200 sets on the DVD media stands alone and cannot receive help from the other 10,119 sets.

(QuickPar also uses a reed-solomon matrix, IIRC.  The difference is in the block size and the number of blocks.)

That's the primary difference with QuickPar.  QuickPar builds a single set for the entire disc (rather then ~10,200 sets).  The downside is that you need hours to build the image due to the large number of blocks, and you can't get block size below ~140KiB (QuickPar has a limit of roughly 32,000 source blocks).  Plus you need lots of RAM to hold the matrix while you calculate it (so smaller "sets" = less memory required).

The "adaptive reading strategy" can be summed up as... assuming you have the recovery file, it only reads enough data off the media to allow for repair/recovery.  (Similar to if you had a set of PAR2s you only pull down enough RARs from USENET to complete a repair.)  With the small block size (2048 bytes) and block count (223) this is probably pretty quick so it doesn't matter that you're doing a maximal repair.

----

Which is better? 

It's probably even for cases where you're ripping to an ISO file and creating PAR2 files off of the ISO.  In both cases, you're planning on storing the recovery data separate from the source data (even if it's in a 2nd session on the media).  In both cases you'll be able to recover data but on marginal discs (severe damage) QuickPar might win out due to treating the entire disc as a single "set".  It all depends on the pattern of damage and how many recovery blocks you have to work with.  OTOH, dvdisaster packages both the ripping and error correction into a single piece of software.

It's surely a bit more user-friendly then using ISO-Buster + QuickPar on the resulting ISO files.  At least, for the specific task of creating recovery data for CD/DVD discs.  Probably worth looking at for pre-recorded media.

I don't see "no variable blocksize" as being an issue.  Since it's targeted at physical CD/DVD media, it does make sense to match the block size of the media (2048 bytes).  However, I'm not sure why they picked 223 as the number of blocks per set.  (Other then it's "prime" and less likely to form patterns as you spiral along the data track of the media?)