Laserdisc dropout removal workflow for FCPX - looking for recommendations

[Marcoq]

Hi everyone,

I'm working on a restoration project of Dragon's Lair (1983, NTSC, Starcom pressing) decoded from a Domesday Duplicator RF dump using ld-decode and ld-chroma-decoder (ntsc2d decoder with phase compensation).

The output is a ProRes 4444 file that I'm editing in Final Cut Pro X. The video quality is generally good but I have the classic laserdisc dropout artifacts — horizontal colored lines caused by physical damage/dirt on the disc surface during the original RF capture.

I've already run ld-dropout-correct on the TBC file before chroma decoding, which helped significantly, but some dropout lines are still visible, especially in scenes with flat colored areas.

My current post workflow is:
- ld-decode → ld-dropout-correct → ld-chroma-decoder → ProRes 4444
- FCPX for color grading
- Topaz Video AI for denoise and upscale

The problem with Topaz is that it desaturates the dropout lines instead of reconstructing the color, so I end up with grey/white lines instead of colored ones — which is arguably worse visually.

My questions:
1. Is there any plugin compatible with Final Cut Pro X (FxPlug) that specifically handles dropout concealment or horizontal line repair with proper chroma reconstruction?
2. Would a temporal median filter applied in FFmpeg before importing into FCPX be effective for this type of artifact?
3. Has anyone had success with a specific workflow for this kind of laserdisc dropout in a modern NLE?

Any suggestions are appreciated. Thanks!

[Selur]

without a sample, I would suggest trying SpotLess,...

[Marcoq]

Thank you for the answer, i uploaded a short sample for a quick look.

Im sorry but idk this software, please could you be more detailed?

[Selur]

Sadly, SpotLess won't work.
It would remove most of these lines, but it will also do something like the attached image.
Maybe RemoveDirtMV or DeSpot could work (also Avisynth/Vapoursynth filters; DeSpot ).
You might want to try i.e. StaxRip as an Avisynth/Vapoursynth interface.

[Selur]

Okay, SpotLess with a radius of 1 doesn't cause the issue above, but also will not remove those artifacts.
You using Vapoursynth or Avisynth would probably require some custom scripting.
Maybe NeatVideo might be worth a try.


A quick&dirty try (script https://pastebin.com/AchDrRBj)

[Sharc]

Here another attempt (blurring + denoising using Avisynth):

BSSource("test_20000.mov")
ori=last
bilinearresize(width/2,height/2).spline36resize(width,height) #downscale -> upscale
temporaldegrain2(degrainTR=3) #denoise
stackhorizontal(ori,last) #display original left, "fixed" right

[DTL2023]

Median and median-like filters greatly depend on the number of degraded frames in a sequence (better only 1 bad frame with 2 and more good around it) and quality of motion compensation for moving parts.

Currently for AVS we have mvtools and RIFE based motion compensation engines and a few median (and median-like) filters. Some of them are implemented in SpotLess script. Also some new ideas exist to save moving parts better (but it may also left more defects at these parts) - https://github.com/Asd-g/AviSynth-vsTTempSmooth/pull/15#issuecomment-3987282845 . But it still requires months of experiments and testing. Sample-based versions may be not best and block-based need more time to implement. Maybe wait some time till about mid of 2026 and some better results may be ready to use.

Sample shows there is a lot of sequential frames are damaged in the same parts of the frame and only partial repair possible with median-like filters.

Also it looks like the NTSC decoding software does not fix chroma subcarriers at the damaged lines - it is better to fix before filtering. And second issue is lines phase shift at the damaged blocks of lines causes vertical lines bending. It is also better to fix before final filtering because it will stress the motion compensation engine. The settings of the RF decoder may be tweaked for the lower sensitivity of the PLL for sync damage (if the real line frequency from laser disc is stable enough).

One general solution about non-stable physical sources restoration is to capture several times with same or better different hardware and process them with median-like filters. The NTSC decoder of software and hardware type may produce different results and the majority-selection software can select the most probable looking parts of the frame (where most of decoders/capture hardware output the same source image). If several capture runs do not damage the source media (true for optical disks I hope) and produce non-equal results it is a good sign of possibility to fix some intermediate processing errors with median-like filtering.

[Marcoq]

Really thank you guys for all the input and time that you spend to help me with this preservation project.

Sample shows there is a lot of sequential frames are damaged in the same parts of the frame and only partial repair possible with median-like filters.

Yes, exactly DTL2023, Dragon's Lair footage is a cartoon made with continuously fast sequences, probably hard to handle with median-like filters. It would be better maybe to extract each frame and elaborate the most noisy ones with the help of AI in some way, just to have some correct sequence to use with this filter.
I will test anyway, there is no rush for this project and I could also give feedback with some very problematic footage.

Here another attempt (blurring + denoising using Avisynth):

Wow, so impressed about the result, it's a huge step forward. I think I could handle it after with Topaz, which already removes some noise even worse than what I saw in your test footage.
I will definitely give it a try.

Okay, SpotLess with a radius of 1 doesn't cause the issue above, but also will not remove those artifacts.
You using Vapoursynth or Avisynth would probably require some custom scripting.
Maybe NeatVideo might be worth a try.

Super interesting tool, but is it Windows only? Nothing for Mac?
I have the demo version of Neat Video for FCPX, probably not as performing as the desktop ones. Also this one that you showed me — can I save the file without a watermark? It would be interesting to try as well.

[DTL2023]

" Dragon's Lair footage is a cartoon made with continuously fast sequences, probably hard to handle with median-like filters."

I see lots of frames are duplicated (or at least big parts of frames like backgrounds) and it is good for temporal-median algorithms. Can you make several captures of the same disk to see how the defects are located and possibly changed in the same frames ?
With analog part in a capture graph you anyway lost some signal to noise ratio at the amplifiers and demodulators and other stages and several capture runs with filtering of common part may make result better without complex processing like attempt to restore too damaged parts with AI/NN with worse result.

"Windows only? Nothing for Mac?"

AVS+ can run on macOS https://github.com/AviSynth/AviSynthPlus . But external filters need to be rebuilt too. Many 'abstract' filters do not use any OS-specific API so can be compiled for macOS too. But not all such filters has instructions and tested - you may need help of programmers to compile all required plugins for temporal (or many-captures/many-processing ways) median-like filtering.

[Marcoq]

You are right about the duplicated frames, I didn't think about that advantage.

Unfortunately I cannot make multiple captures since I'm working from a single RF dump
downloaded from the Internet Archive - I don't own the physical disc. So I only have
one capture available.

That said, since Dragon's Lair is CAV and the same animation frames repeat many times
throughout the disc, would it be theoretically possible to use those repeated frames
(same CAV frame number appearing at different time positions) as a substitute for
multiple captures? The ld-decode JSON metadata contains the CAV frame numbers for
each decoded frame, so it might be possible to identify and align matching frames
from different positions in the same capture.

[aramkolt]

An interesting project to be sure - You really do need another RF capture from ideally 1 or 2 additional discs to really restore this properly, though I can see why that probably isn't feasible given that they seem to be listed for $350-$400 on eBay and you might not have the DD hardware yourself. I kind of followed a project where they were people much smarter than me were trying to restore the full screen version of a Japanese anime film that looked best on laserdisc, but also was prone to disc rot. They ended up doing RF capture from 3 different discs and doing some type of median processing to make a single file.

There are programs that can identify duplicate frames, but typically they are looking for duplicates that are all right next to each other in the sequence. I'm not sure if with an RF capture if they are going to technically be duplicates however as it's still analog and won't be likely exactly the same digitally.

What you could try is export all of the frames as an image sequence and then manually identify the frames that have issues first, then copy other frames that you find to be the same and then copy those and rename them to take the correct position in the sequence, replacing the bad frames. From there you'd just need to re-compile the image sequence into a video again.

[aramkolt]

The horizontal wobble on the lower part also is kind of questionable, I haven't really seen that on laserdisc RF captures. Kind of makes me wonder if the disc itself was warped or the player was misaligned maybe? You'd think the decode software would correct those sorts of line time base errors.

[jagabo]

I would try using a Panasonic ES10 or ES15 in passthrough mode for it's line TBC.

[Sharc]

I would try using a Panasonic ES10 or ES15 in passthrough mode for it's line TBC.

This kind of wiggle can be nicely fixed with vcmohan's DeJitter filter:
http://www.avisynth.nl/users/vcmohan/DeJitter/DeJitter.htm

Avisynth script:

BSSource("test_20000.mov")
DeJitter(jmax=10,th=0.03,wsyn=4)
bilinearresize(width/2,height/2).spline36resize(width,height)
cas(0.9)
temporaldegrain2(degrainTR=4)

[DTL2023]

" the same animation frames repeat many times
throughout the disc, would it be theoretically possible to use those repeated frames
(same CAV frame number appearing at different time positions) as a substitute for
multiple captures?"

I do not see many repeated frames. I see many frames are duplicated (only 2 copies present). This is not the best case for classic median-like algorithms. They need at least 2 good frames for each 1 bad frame. With sample and block levels of granularity the 3 (or more) same frames may have non-overlapped damages too.
With only 2 partially good frames it only partially helps and needs an additional weighting channel to select the good part from damaged. Additional channels may be some analysis of the colour or Fourier frequency spectrum or some structural similarity (from SSIM metric - the covariance).
Possible algorithm for 2 temporal frames with additional metrics weighting:
For each 2 blocks from each 2 measured frames (at least 2x2 or better 4x4 and larger) calculate similarity metric of current block with (all or at least many) surrounding blocks and get 2 simple numerical similarity metrics M1 (1st frame block with all frames all blocks) and M2 (2nd frame block with all frames all blocks) for comparison. If M1 > M2 - select 1st frame block to output. If M1 < M2 - select 2nd frame block to output. This idea about damaged blocks is not the same as most of the good frame area. The metric may be any block-friendly like SAD/SSIM/VIF and others.
But for best results this need to be applied only to real same duplicated frames of the animation. If there is some real motion between frames it will be additionally distorted.
And auto-detection of the significantly (>20..30%) damaged frames for being really small framerate animation duplicates is not very easy too. Better to really separate all footage to frames and manually (or semi-auto) separate real duplicates for next processing.

"The horizontal wobble on the lower part also is kind of questionable, I haven't really seen that on laserdisc RF captures. "

If only RF capture is available it may be an additional issue of the RF decoding software and better need to be fixed at the decoding stage. The damaged part of the RF data also has damaged line sync/start data and may cause such shifts in the decoding software (and hardware). So the first questions to analyse is:
1. Is real RF data stable ? If yes - fix line shift in RF decoding software by simply disabling slow PLL to input damaged sync data. Look in the sources of RF decode how it attempts to do line timing resync inside the frame.
2. Is real RF data sampler sampling frequency was stable (mostly yes if it was not PLL-ed to input signal with defects).

"This kind of wiggle can be nicely fixed with vcmohan's DeJitter filter:"

Yes - very good result. Though vertical /2 resize may damage some possibly present vertical resolution data.

[Marcoq]

The horizontal wobble on the lower part also is kind of questionable

Thank you for pointing that out. DTL2023 gave a very detailed explanation about this below - it seems to be related to damaged line sync data in the RF signal causing the decoding software to misread line timing. I will look into the ld-decode PLL settings to see if it can be tuned to ignore damaged sync data.

I would try using a Panasonic ES10 or ES15 in passthrough mode for it's line TBC.

Unfortunately I don't have access to physical hardware TBC since I'm working from an existing RF dump from the Internet Archive. The DeJitter approach that Sharc suggested based on your observation looks very promising though.

I would like to share that there is another "HQ" version derived from the digital copy extracted from MAME as a .CHD file, which I converted. It looks pretty similar but with completely wrong color grading.

There are also good copies of this game available as .M2V files, but I chose to ignore them since they have gone through multiple transcoding processes that degrade video quality.

I have already uploaded a "restored" version based on one of those files, but my goal is obviously to start fresh from this laserdisc RF dump instead. I have also reached out to both the laserdisc community and the game's software emulator community to find out if another independent digital capture of the disc exists.

This kind of wiggle can be nicely fixed with vcmohan's DeJitter filter

The result in your sample looks excellent! I would like to test this on my end. As I mentioned earlier, I would prefer to skip the temporaldegrain2 and cas passes for now since I plan to handle denoising separately with Topaz Video AI. Would the DeJitter + resize alone already give a significant improvement, or are the denoising passes essential for the dropout lines specifically?

I do not see many repeated frames. I see many frames are duplicated (only 2 copies present).

Thank you for the very detailed technical explanation. The algorithm you described for 2-frame weighted median selection based on block similarity metrics is very interesting. Given the complexity of implementing this properly, and considering that only partial repair is realistically achievable with this single capture, I think the most practical path forward for me is to combine the DeJitter + spatial resize approach from Sharc with a manual inspection of the worst frames. I will run some tests and post results here.

[Sharc]

... Would the DeJitter + resize alone already give a significant improvement, ....?

Yes.

[Selur]

Uhh,.. I like the DeJitter (totally forgot that this filter exists!)
(https://pastebin.com/egVQ7LcM)

Cu Selur

[Marcoq]

Better and better, last test looks quite perfect.

[Selur]

Playing around trying to avoid downscaling,... (https://pastebin.com/6vC5U6uu)

[Marcoq]

I think the Dejitter sample is still the best result, last one are more clear the small horizontal strime inside the drops.

Still i thind make a test but i would like to try the Dejitter with a sample and see if Topaz its able to rebuild the missing color.

[aramkolt]

Agree there's some issues with horizontal sync, but I thought that was the whole point of decode - in that it would act as a software TBC (both line and frame), so I'm surprised it doesn't correct the horizontal jitter without additional tweaking. It should also be exceptionally good at dropout compensation since it can look back and forwards a frame to determine what areas of "low" RF or dropouts should look like. Granted, dropout compensation can be fooled if there's a ton of movement between frames, but seems there's still visible issues even in areas where there aren't movement.

That's kind of why I'm not sure that decode is the absolute best way to capture video in all situations. On paper it should be the best way, but some of the examples where I either see minimal difference between that and traditional capture, or things that you'd think it'd correct, it doesn't. I need to do some more testing myself, finally got a hold of everything to make ADA4857 amplifiers which should be a good start.

Here's an interesting comparison video which I still think certain aspects of the traditional capture are better, or minimally inferior. I will say the mostly blue background is better for decode, but then again, black magic cards aren't really recommended for capture either and it is unclear if the VCRs internal processing is causing some of the softening in certain areas. Doesn't mean all VCRs and capture chains would do that though.

https://www.youtube.com/watch?v=B2ldecEC_jA

[The 14th Doctor]

I've messed around with other user's decodes with retail VHS tapes, doing more own comparisons. The results just do not impress me.

Quality ranges from slightly worse to kind of the same. Which makes me ask "why should I dump everything I've been doing and switch to a method that is overall much slower and harder to get into?"

The dropout compensator isn't perfect from what I've seen, misses dropouts that I feel like should be easy to mask. I've been dealing with tape based dropouts (ones that happen every time on a given frame no matter the VCR) than dropouts caused by dirty VCR heads.

I really only see myself using it here and there for rare tapes and a small subset of tapes that have close caption data, nothing less and probably nothing more.

It's impressive sure, but it's just not practical due to how much more slower it is.

For anybody reading these are my feelings about Decode in regards to analog tape (VHS, Video8, etc), not LaserDisc. Everybody here can pretty much 100% agree RF capture/decode is the proper way to archive LaserDiscs.

[Marcoq]

Everybody here can pretty much 100% agree RF capture/decode is the proper way
to archive LaserDiscs.

Fully agree. In my case the RF dump was already available on the Internet Archive so I didn't have to do the capture myself. Regarding the decode process I used, here are the exact parameters:

ld-decode version: main branch (7.2.0-6-g54366b9c)
ld-chroma-decoder version: vhs-decode fork (e599ce27)

Decode command:
python3 ld-decode --NTSC --V4300D_notch_filter -t 8 --ignoreleadout input.flac output

VBI processing:
ld-process-vbi -t 8 output.tbc

Dropout correction:
ld-dropout-correct -t 8 output.tbc output_doc.tbc

Chroma decode:
ld-chroma-decoder -f ntsc2d -t 8 -p y4m --pad 8 --ntsc-phase-comp
--chroma-nr 6.0 --luma-nr 2.0 output_doc.tbc - | ffmpeg -i - -vf yadif=0
-c:v prores_ks -profile:v 4444 output.mov

I'm not 100% sure this is the optimal parameter set — especially regarding
--ntsc-phase-comp and the chroma/luma NR values. If anyone sees obvious mistakes
or suboptimal settings in this pipeline I'm very open to suggestions.

I'm surprised it doesn't correct the horizontal jitter without additional
tweaking.

From what DTL2023 explained earlier in this thread, the horizontal jitter in my case seems to be caused by damaged line sync data in the RF signal itself — the decoder PLL picks up the corrupted sync and shifts the line timing accordingly. So it's not really a TBC failure but rather the decoder faithfully reproducing what's in the damaged RF data. DeJitter in post (as Sharc demonstrated) seems to be the right approach for this specific issue.

[aramkolt]

This could be technically wrong, but I think traditional TBCs work by deleting all vertical sync (for frame TBC) and horizontal sync (line TBC) and then replaces that data with digitally precise placeholders that are the correct length so that when the rolling buffered frames are released, that there is precise spacing between each line and frame. So when you say the original sync signals are corrupt, a traditional line TBC (or software TBC) really should not be bothered by that since it would immediately delete or disregard all of that information anyway.

Really all a line TBC does is identify where the start and end of the video information is on each line and then justifies it to the left of the visible image. If you have a second or more generation copy, these sorts of errors compound and you might not correctly identify where the video information starts as accurately as the original, but this being laserdisc shouldn't really suffer from generation losses unless it is baked into all discs of that pressing.

The full frame anime film restoration that I was following that did 3 different RF captures from 3 different laserdiscs and then median filtered to get rid of disc rot damage did have such errors built into it (that one was more vertical jitter rather than horizontal), or they were at least picked up by decode that way repeatably. I tried my own traditional capture of that same pressing of disc and there was no significant jitter present. Not exactly sure what to make of that other than that in some cases, decode can have stability problems that are not seen in traditional captures even with laserdisc.

The one variable I did not test is whether the player itself induced some of those issues (apparently consistently across 3 RF captures) because I was using a different player than the RF captures that they did, all presumably on the same player.

[Marcoq]

Ok more or less i solver the issue about noise

Now i try to remove the interlace effect with Topaz, software works wgood but on some scene create this kind of artifacts

I removed the denoise from the processing beacuse cause a sort of "flame effects" between frames.

[Selur]

Field matching using i.e. TFM works fine,..

[Marcoq]

Field matching using i.e. TFM works fine,..

mmm

Nothing, i was using this command

ffmpeg -i /Users/marco/Desktop/DL_laserdisc_originale/sample_test_30sec.mov \
  -vf "fieldmatch=order=auto:combmatch=full" \
  -c:v prores_ks -profile:v 3 -pix_fmt yuv422p10le \
  -r 25 \
  /Users/marco/Desktop/DL_laserdisc_originale/sample_tfm_auto.mov

[Selur]

Using Avisynth or Vapoursynth works,.. Maybe try order=bff instead of order=auto