Sounds to me like VLC and Kaffeine are using an audio system that other software is not, or they have vastly different settings to the others. Yes, this is entirely possible. Linux audio is an absolute hellscape of incompatible trash. Still. Fifteen years or so after I abandoned trying to get anything moving to improve it. Yay.

Bitter assholery aside, crackling sounds during playback, or generated in a burned file, are a classic symptom of a buffer underrun*. This can be either at the system settings level or software settings level since some software will override the system settings. I would check in the VLC settings, verify what sound system it’s using, and basically just compare all of the settings to the software that’s creating the problem. I’d be willing to wager that you’ll find some weirdness going on. Match the VLC settings as much as you can and go from there.

I highly doubt this is a hardware issue. It would make no sense for it to be if you can do the thing without problem in some software but not others.

*For anyone that doesn’t know, a buffer underrun is something that us poor CD-burning bastards had to deal with back in the 20th century. To a different extent it still exists with audio interfaces in a way that may be relevant here. To burn or play back the audio the system allocates a buffer, a small amount of memory that it reads the audio into, in an attempt to keep the device from running out of data to replicate (sort of… basically… it’s complicated, look it up). If the device was able to burn or read the data faster than the system could provide the data you’d get a buffer underrun, which ended up sounding like weirdass crackly noise but not in a good way since it was just digital garbage. You can get a similar effect now if you use an audio system that allows you to change the latency settings. This is essentially the same buffer, different day. The smaller the buffer the lower the latency, but you risk running out of buffer and generating a horrific crackle. Raise the latency, increase the buffer, you are less likely to create underruns.

Note that at some technical level everything I just said is probably incorrect, but it’s the best kind of incorrect… the kind that will get the problem fixed regardless of total accuracy.

What CD ripping software are you using? When were the CDs you’re struggling to rip pressed? In particular, were those CDs distributed at the height of the CD ripping panic of the turn of the millennium when rootkits and other nasty tricks were used widely. Depending on the software’s approach to ripping, defects,like scratches or non-standard audio tracks, that a simple player might simply skip over without much more than a blip could confuse the ripping software. I vaguely recall some early copy protection scheme using this exploit to deter CD rips by making CDs that appeared normal in dumb CD audio players, but confused PCs attempting to rip audio tracks that were expected to follow the Redbook standard, but didn’t.

I’ve had some success getting accurate rips using morituri whipper (Morituri is no longer actively maintained, Whipper is an active fork). It’s command line output and logs might offer some insight about the exact problem you’re having with these CDs. I’m pretty sure that given the way Morituri/whipper works it can bypass all but the most “damaged” audio tracks.

Do you have tags on your tracks? Old FLAC versions have issues with tags, resulting in crackling. Try to use flatpaks whenever possibile.

Did you try playing the files on a different device to sort out playback issues?

I assume there’s a data cable running from your optical drive to the motherboard. Check that it’s undamaged and firmly seated at both ends, because this kind of sounds like a bad connection (which some players might be able to compensate for with filters). Even if you didn’t replace the cable or the mobo, you might have unseated one end while you were messing around inside the case.