Clock Frequency Issues on a Famicom

I've been having problems with a Famicom I'm fixing/modding. I performed an A/V out mod on it as per this tutorial.
http://jpx72.detailne.sk/modd_files/fc/avmod.htm

After performing the mod and powering the system on, I had static on the TV and slowed down sound on the Famicom. I'm interpreting this as an issue with the crystal oscillator or the circuit that it's a part of. My understanding of how clock speeds on the Famicom work is it divides the 21.477272 MHz clock by 12 for the CPU and by 4 for the PPU. Since I'm getting slowed audio and a bad video out signal, it would seem to me that the problem is occurring somewhere before the signal is divided for either chip.

I've replaced the oscillator and all the capacitors on the main Famicom board but I can't find any problems with them. I've played with the variable trimmer capacitor (and replaced it), and every time I turn it the system crashes and all the sound stops. After cycling the power the system starts up again at the same speed no matter what position the trimmer is in.

I'm not sure if the Famicom had these issues before I did the mod because I could not get any video out signal from it. It also appears that the previous owner has also attempted an AV out mod. As far as equipment goes I don't have a oscilloscope to measure frequencies directly so I'm operating a little blind.

Does anybody have any more info on the oscillator circuit and/or what could be wrong with it? Could I have fried something inside the PPU or CPU?

"slowed down sound" and "static on the TV" implies the PPU might be partially broken. But it sounds like the CPU and clock source are probably ok.

When you say "static on the TV" does it look like normal over-the-air TV white noise? Or more patterned? (If the latter, take a picture of it?)

There's definitely a pattern to it. I can see the pattern change slightly whenever the title screen ends and switches to a gameplay demo. That's why I thought it was a clock issue, there's some kind of video signal but I think it's being sent at the wrong frequency. I could see how this could be caused by the PPU though. Is sound (the APU) driven by the PPU or the CPU? My assumption was it was driven by the CPU.

Pictures of Static (I can't seem to upload files so they're on imgur instead)
https://imgur.com/a/5UGuT

The CPU clock directly affects the pitch of the sound, but most music engines use the PPU (i.e. the vblank interrupt) to control the rate at which the audio updates, which is normally 60 times per second. If the music notes are correct but the tempo is slowed down, that could mean that the PPU is not generating interrupts at the correct rate.

The pitch of the sound isn't changing, but how fast the notes are being played are. I'll try switching out the PPU and seeing how that goes.

Also, Dragon Quest 1, 2, and Door Door use only the CPU (APU frame counter instead of vblank) for timing the sound. If you have a Dragon Quest 1 or 2 cartridge, you can test that.

Some things have happened since my previous post. I've acquired another Famicom from the same source (which I'll refer to as unit two, and the previous Famicom as unit one) and attempted the same mod with the same result. Slowed down sound, heavily distorted image on the screen. The image on unit two is slightly better, I can just barely make out a black and white title screen underneath all the rolling static. Unit two was in much better (nonworking) condition but still looked like someone had attempted an AV out mod on it, there were three jumper wires on the main circuit board and an aftermarket oscillator crystal (which I replaced with a genuine crystal off an NES). I've also acquired a Rigol DS1052E digital oscilliscope for further hardware debugging (though I'm still learning how to use it). I don't have a Dragon Quest 1 or 2 cartridge so I can't yet test the theory of a broken PPU.

My next steps are ordering some LTC1799 variable oscillators, hooking one each up to the CPU and PPU independently, and seeing if an increase in clock speed on either of them will fix the problem. If this fixes it the problem must lie somewhere in the clock signal division circuitry or internally in the chips.

If anyone sees a problem with this setup or has any further observations please let me know.