e2fsck deletes many inodes, recovers too little data from a disk image. Are there better methods?

I imaged a failing SSD as best I could using ddrescue or dd (it's been too long to recall which). With the resulting .img, I've burnt a disk which is not recognised as mountable.

Using e2fsck -fyvC 0 upon the disk, I'm able to subsequently mount it, recovering some, but certainly not all, files originally on the SSD.

Is this the best option I'd have for data retrieval, or is there a better tool which could recover more?

Running e2fsck with the above flags, I receive various warnings about orphaned or deleted inodes, which are either fixed or deleted. Unfortunately, these seem to correspond to the data I'm most seeking from the disk.

The output is 227,000 lines, but some highlights below:

ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear? yes

*** journal has been deleted ***

Superblock has_journal flag is clear, but a journal is present.
Clear? yes

Truncating orphaned inode 6302578 (uid=1000, gid=1000, mode=0100664, size=3600)
Pass 1: Checking inodes, blocks, and sizes

[...]

Inode 1048618 was part of the orphaned inode list.  FIXED.
Inode 1048634 was part of the orphaned inode list.  FIXED.
Deleted inode 1048662 has zero dtime.  Fix? yes

[...]

Entry '..' in <6291748>/<9965526> (9965526) has deleted/unused inode 6291748.  Clear? yes

[...]

Unattached inode 9712327
Connect to /lost+found? yes

Inode 9712327 ref count is 2, should be 1.  Fix? yes

[...]

Free blocks count wrong for group #740 (32768, counted=3012).
Fix? yes

[...]

Directories count wrong for group #4593 (0, counted=114).
Fix? yes

[...]

Padding at end of inode bitmap is not set. Fix? yes

Recreate journal? yes

Creating journal (262144 blocks):  Done.

*** journal has been regenerated ***

/dev/sdc: ***** FILE SYSTEM WAS MODIFIED *****

     2205797 inodes used (4.52%, out of 48807936)
       20864 non-contiguous files (0.9%)
        1884 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 2154021/1685/13
   128999150 blocks used (66.08%, out of 195210139)
           0 bad blocks
          18 large files

     1869601 regular files
      282774 directories
          10 character device files
           1 block device file
           5 fifos
  4294963048 links
       53513 symbolic links (50169 fast symbolic links)
          14 sockets
------------
     2164179 files

Are there more advisable methods of data recovery here? Thanks in advance for any assistance.