Checklist
Bug Description
ld-decode appears to have especially great difficulty recovering LaserDisc EFM from some RF captures.
I noticed this because digital audio produced using the normal ld-decode → Decode-Orc process contains severe corruption and silence in some sections. However, when the exact same RF capture is decoded directly to PCM using MuseLD/ac3rf, the result is dramatically better.
Both pipelines perform their own error correction/concealment, so I am primarily comparing the practical recovery obtainable from the same captured RF:
- RF → ld-decode → EFM → Decode-Orc → PCM
- RF → MuseLD/ac3rf → PCM
MuseLD is able to recover generally very good audio from the same RF that results in severe corruption through the ld-decode + Decode-Orc path.
Steps to Reproduce
- Decode
Problematic Digital Audio Sample.ldf (linked elsewhere) with ld-decode to produce EFM:
~/ld-decode/ld-decode \
--NTSCJ \
"Problematic Digital Audio Sample.ldf" \
"Problematic Digital Audio Sample"
-
Decode the resulting EFM audio using Decode-Orc as normal.
-
Decode the exact same RF sample directly to PCM using MuseLD/ac3rf:
./ac3rf-efm-decode \
--efm-rf \
--output-filename "Problematic Digital Audio Sample ac3rf.pcm" \
"Problematic Digital Audio Sample.ldf"
- Compare the resulting PCM audio.
Expected Behaviour
I would expect ld-decode + Decode-Orc to recover broadly similar digital audio from the RF capture to MuseLD, allowing for differences between the two decoders' error correction and concealment methods.
In particular, sections that MuseLD can recover cleanly from the RF should not result in severe corruption when processed through ld-decode.
Actual Behaviour
The ld-decode + Decode-Orc result contains severe bursts of corrupted digital audio in the attached sample.
MuseLD/ac3rf, decoding directly from the exact same RF capture, recovers the section dramatically better and produces generally very good audio.
This suggests that substantially more recoverable EFM information is present in the RF capture than is ultimately being recovered through the ld-decode path.
Environment
- ld-decode version: current
main, commit 1891ac676f7a102cfb2c639cd6da6d63ffe011c7
- Operating System: Ubuntu 24.04
- Hardware Used: Lenovo Legion 5 15IMH05H
- RF sample rate: 40 MS/s
Additional Information
I deliberately selected a short section from a disc that produces an unusually high digital-audio error count with ld-decode.
The attached screenshot shows the difference clearly: the ld-decode + Decode-Orc result contains extensive corruption, while MuseLD's direct RF-to-PCM result from the same capture is much cleaner.
I have also tested MuseLD on longer portions of this capture and have generally obtained very good recovery, so the RF appears to contain substantially more usable digital-audio information than the ld-decode + Decode-Orc result would suggest.
Checklist
Bug Description
ld-decode appears to have especially great difficulty recovering LaserDisc EFM from some RF captures.
I noticed this because digital audio produced using the normal ld-decode → Decode-Orc process contains severe corruption and silence in some sections. However, when the exact same RF capture is decoded directly to PCM using MuseLD/ac3rf, the result is dramatically better.
Both pipelines perform their own error correction/concealment, so I am primarily comparing the practical recovery obtainable from the same captured RF:
MuseLD is able to recover generally very good audio from the same RF that results in severe corruption through the ld-decode + Decode-Orc path.
Steps to Reproduce
Problematic Digital Audio Sample.ldf(linked elsewhere) with ld-decode to produce EFM:Decode the resulting EFM audio using Decode-Orc as normal.
Decode the exact same RF sample directly to PCM using MuseLD/ac3rf:
./ac3rf-efm-decode \ --efm-rf \ --output-filename "Problematic Digital Audio Sample ac3rf.pcm" \ "Problematic Digital Audio Sample.ldf"Expected Behaviour
I would expect ld-decode + Decode-Orc to recover broadly similar digital audio from the RF capture to MuseLD, allowing for differences between the two decoders' error correction and concealment methods.
In particular, sections that MuseLD can recover cleanly from the RF should not result in severe corruption when processed through ld-decode.
Actual Behaviour
The ld-decode + Decode-Orc result contains severe bursts of corrupted digital audio in the attached sample.
MuseLD/ac3rf, decoding directly from the exact same RF capture, recovers the section dramatically better and produces generally very good audio.
This suggests that substantially more recoverable EFM information is present in the RF capture than is ultimately being recovered through the ld-decode path.
Environment
main, commit1891ac676f7a102cfb2c639cd6da6d63ffe011c7Additional Information
I deliberately selected a short section from a disc that produces an unusually high digital-audio error count with ld-decode.
The attached screenshot shows the difference clearly: the ld-decode + Decode-Orc result contains extensive corruption, while MuseLD's direct RF-to-PCM result from the same capture is much cleaner.
I have also tested MuseLD on longer portions of this capture and have generally obtained very good recovery, so the RF appears to contain substantially more usable digital-audio information than the ld-decode + Decode-Orc result would suggest.