efm-decode-f2 crash (Fatal: Subcode::fromData(): Invalid Q-mode nybble! Must be 1, 2, 3 or 4 not 9)

[staffanu]

Checklist

• [x ] I have searched the issues page for any duplicate issues open or closed and confirmed that this bug has not been reported before.
• [ x] I have tested the issue with the current build.
• [ x] I have attached log files, uploaded sample data, and commands used so that the issue can be easily reproduced by the developers.

Bug Description

I'm running efm-decode-f2 on the attached file.

Steps to Reproduce

$ efm-decoder-f2 --no-timecodes f2-decode-error.efm

Expected Behaviour

The file is known to contain many errors, but the tool should not crash.

Actual Behaviour

Tool crashes.

Environment

• Decode version: [e.g., 1.2.3]
• Operating System: [e.g., Windows 10, macOS Big Sur, Linux Ubuntu]
• Hardware Used: [e.g., Ryzen 7 7950x, 16GB DDDR5-4400mhz, SSD NVME Gen 3 etc]

$ efm-decoder-f2 --version
efm-decoder-f2 Branch: main / Commit: e54ca76
(I pulled from github today)

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 25.10
Release: 25.10
Codename: questing
$ uname -a
Linux ThinkPad-X1 6.17.0-8-generic #8-Ubuntu SMP PREEMPT_DYNAMIC Fri Nov 14 21:44:46 UTC 2025 x86_64 GNU/Linux

Hardware is 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz (from /proc/cpuinfo). It is a Lenovo Thinkpad Carbon X1, gen 9.

Additional Information

I trimmed the file to being quite short while still reproducing the problem. If you want a longer excerpt then please let me know! (stu6952 on Discord).

Is it related to tbc-video-export?

No

f2-decode-error.efm.gz

[simoninns]

I made a fix to the subcode decoding to prevent the crash - but even with that it looks like the input EFM is mostly junk... What is the source of this EFM? (...and if you include more EFM data (rather than the attached snippet) does it get anything back?).

./efm-decoder-f2 ~/tmp/f2-decode-error.efm ~/tmp/out.f2 --debug
Debug: Version - Git branch: main / commit: e54ca76d
Info: Beginning EFM decoding of "/home/sdi/tmp/f2-decode-error.efm"
[2026-01-03 17:23:09.612] Debug: EfmProcessor::process(): Decoding EFM from file: "/home/sdi/tmp/f2-decode-error.efm" to file: "/home/sdi/tmp/out.f2" 
[2026-01-03 17:23:09.612] Debug: ReaderData::open() - Opened file "/home/sdi/tmp/f2-decode-error.efm" for data reading with size 13312 bytes 
[2026-01-03 17:23:09.612] Debug: WriterF2Section::open() - Opened file "/home/sdi/tmp/out.f2" for data writing 
Info: Progress: 7 %
[2026-01-03 17:23:09.612] Debug: F3FrameToF2Section::expectingInitialSync - Found sync0 frame after discarding 1 frames 
Info: Progress: 15 %
Info: Progress: 23 %
Info: Progress: 30 %
Info: Progress: 38 %
Info: Progress: 46 %
Info: Progress: 53 %
Info: Progress: 61 %
Info: Progress: 69 %
Info: Progress: 76 %
Info: Progress: 84 %
Info: Progress: 92 %
Info: Progress: 100 %
Info: Flushing decoding pipelines
Info: Processing final pipeline data
Info: Decoding FAILED
Info: F2 Section Correction stage did not complete lead-in detection successfully.
Info: This could be due to invalid input data or due to missing timecode information in the input EFM.
Info: If you think the input EFM is valid - try running again with the --no-timecodes option (in case the input EFM is not ECMA-130 compliant and does not contain timecodes).
[2026-01-03 17:23:09.614] Debug: ReaderData::close(): Closed the data file "/home/sdi/tmp/f2-decode-error.efm" 
[2026-01-03 17:23:09.614] Debug: WriterF2Section::close(): Closed the data file "/home/sdi/tmp/out.f2" 

[staffanu]

Hi -- I temporarily uploaded a longer EFM file (with t values) to https://madeye.org/~staffanu/DAYU.efm . If I run this through my EFM decoder at https://bitbucket.org/staffanulfberg/ldaudio/src/master/ac3rf-decode/ using:

ac3rf-decode --efm-t-values --log 4 --output-filename DAYU.pcm DAYU.efm

the tool reports lots of errors but the result is quite listenable. So, I encountered this when I wanted to compare a bit with the ld-decode tools.

If you don't want to download/compile, this is the result: https://madeye.org/~staffanu/DAYU.pcm (raw 16 bit signed samples)

[simoninns]

This doesn't look like valid EFM data - I can see the tool you are comparing to is AC3 (which isn't the same thing as it varies from the IEC standards). efm-deocoder is an EFM decoder for the IEC standards, it doesn't support AC3 streams

[simoninns]

I'll PR in some changes that improve the validation (so the tool handles the invalid EFM data more cleanly) - but AC3 support won't magically appear :)

[simoninns]

Pull request #1001 merged - please feel free to raise a separate issue for AC3 support

[staffanu]

I've pulled the fix -- now the tool doesn't crash!

Just to say that everything I've been discussing in this issue is EFM related. It just so happens that the "ac3rf-decode" tool also can decode efm (from RF, baseband, or, very recently, from ".efm" files with "t values" created by ld-decode). And yes, the tool's name should change since the name is confusing. It started out as an AC3-RF demodulator tool.

I uploaded https://madeye.org/~staffanu/DAYU.lds now. The .efm file was created using ld-decode from this file. Yes, there are lots of errors but it is clearly EFM. For reference, the ac3rf-decode tool seems to pass the CRC in about 1/100 of the Q channel frames. I would have hoped that the "--no-timecodes" option would basically make Q frames unimportant.

[simoninns]

If that's the case I have no idea why it's not decoding - according to the decoder the EFM contains no valid F2 syncs (which is atypical of an AC3 source iirc). Do you have a link to the laserdisc in some online laserdisc DB that might provide a clue as to the type of digital encoding it has?

[staffanu]

No I'm sorry -- I received this sample when asking for problematic samples on Discord. I was told it is from a Chinese Karaoke LD that does not have an lddb entry, from a manufacturer called "Primco". Looking at dac_f2sectioncorrection.cpp it seems to me that if there is no valid metadata, the Got invalid metadata section whilst waiting for first section. error will always be triggered, since it comes before any checks for m_noTimeCodes. I tried changing this slightly but failed since I don't really have a grasp on how the code is supposed to work.

That being said, ignoring the metadata does produce a somewhat playable audio file (using the other tool). Notice that this is true also when using the t-values output from ld-decode as its input.