happycube / ld-decode Goto Github PK

Let's start on documenting this awesome piece of code! Time to make a Wiki :)

The ld-analyse application should make it clearer as to what metadata is present. For the VBI "not present" should be "no metadata". For highlight dropouts, the option should be unavailable if no dropout metadata is present. Same for the VBI and NTSC dialogue windows.

There are two potential PAL comb filters that may offer a better approach that should be looked into (especially if the author of the filter is willing to lend some assistance). The two interesting ones found so far are:

The BBC transform PAL decoder designed by Jim Easterbrook:
http://www.jim-easterbrook.me.uk/pal/
https://github.com/jim-easterbrook/pyctools-pal

Software-based PAL colour decoding designed by Andrew Steer:
http://www.techmind.org/vd/paldec.html

There is some form of misalignment of the video lines in PAL decodes. Please see the attached TBC output:

The ld-decode project uses a mixture of ld-decode (tools, repo name, directories) and lddecode (for the primary python executable); it would be nice if it all matched (i.e. use ld-decode throughout to keep things standard)

There is definitely some work to be done with the PAL filter setup even aside from MTF

Also it appears the DD captures would benefit from auto-adjusting filters.

In order to provide decode of the data stored on the Domesday LaserDiscs as well as access to digital audio and AC3 audio on later LaserDiscs it is necessary to demod and filter the EFM signal from RF captures. The EFM can then be decoded into a bit-stream for further processing.

At some point (after LD is settled) I'd like to also decode VHS video RF (due to the way HiFI signals are encoded, it would require a second channel).

If someone with a DdD setup can get quality VHS captures, this might get sped up a bit :)

This causes and issue compiling the ld-decode-tools ld-comb-ntsc on mac:

comb.cpp:732:83: error: use of undeclared identifier 'M_PIl'; did you mean
'P_PID'?
...double>(y), x) * (180 / M_PIl));
^~~~~
P_PID

This can be fixed by defining the constant by hand:

#ifndef M_PIl
#define M_PIl 0xc.90fdaa22168c235p-2L
#endif

The TBC PAL output is missing data for scan-lines 605 to 610. Reading the TBC file into the colour filter application shows nothing but zero on these lines.

I checked the TBC output with a hex editor and there are clearly gaps in the data.

Whilst I was testing the VBI decoding functionality in ld-decode-tools I came across a very odd decode for one of my test files. The source .lds is on the SFTP - here are the details (from my VBI testing notes):

Dead Man Walking - side 1 - NTSC CLV (chapter boundary)
00:20:28 - Chapter 3
00:20:32 - Chapter 4

python3 lddecode.py /SFTP/VBI_Test_Captures/Dead\ Man\ Walking_CLV_NTSC_side1_00H20M28S-00H20M32S_2018-11-06_09-31-30.lds ~/lddecode_out/Dead\ Man\ Walking_CLV_NTSC_side1_00H20M28S-00H20M32S_2018-11-06_09-31-30

Really odd decode of first 20 frames or so...

Hi Chad,

Having been looking at the "oscilloscope" view of various colourbars and testcards, I've noticed that the rising edge of a white bar has a softer final-attack, and a harder initial-decay - see image.

Is there some kind of IIR (time-asymmetric) filter in your FM demodulator code, or is this likely an artifact of analogue processing in the source material / when the discs were mastered?

The line start would remain the end of HSYNC, but to reduce confusion the entire line period should be output. This is particularly useful for PAL debugging as the pilot signal (albeit clipped) could be seen/analyzed.

http://screenshotcomparison.com/comparison/122558

I'm going to look at this in rev2/seaking once I get things stabilized on rot disks.

When dealing with NTSC CAV, NTSC CLV, PAL CAV and PAL CLV the field order/alignment doesn't seem to be the same in the output from ld-decode.

Since downstream applications cannot determine the field order easily (and the output is always interlaced), ld-decode should output all disc and video types in the same way otherwise things like VBI decoding will be very difficult to implement.

In several PAL decodes there seems to be a form of colour banding. The following image is post-colourization, but the banding is visible in the TBC output:

decode command was:

python3 lddecode.py /media/sdi/Seagate\ Backup\ Plus\ Drive/SFTP/Jason\ ATA\ Disc\ 4/JasonPAL_d4_tc1.lds ~/Capture/hc_test3 0 10

Frame #4 (although it shows on the other frames too)

Commit: b93ef4e

I tried my sample of Erica last night and the current framing/TBC code couldn't deal with it.

(Planning to fix in Seaking dev cycle, since Combi is frozen.)

Command to recreate:
sdi@sehotitan01:~/github/ld-decode$ python3 lddecode.py /media/sdi/Seagate\ Backup\ Plus\ Drive/SFTP/LDV4300D_2\ Captures/AIV/Domesday_DiscSet2/Domesday\ National_CAV_PAL_side1_Disc\ set\ 2_2018-10-02_18-14-36.lds ~/lddecode_out/DD_National_testcards --pal --start 1856 --length 20 --field

Result:
Namespace(MTF=1.0, MTF_offset=0.0, cut=False, end=-1, field=True, infile='/media/sdi/Seagate Backup Plus Drive/SFTP/LDV4300D_2 Captures/AIV/Domesday_DiscSet2/Domesday National_CAV_PAL_side1_Disc set 2_2018-10-02_18-14-36.lds', length=20, ntsc=False, outfile='/home/sdi/lddecode_out/DD_National_testcards', pal=True, seek=-1, start=1856)
Traceback (most recent call last):
File "lddecode.py", line 121, in
picture, audio = field.downscale(linesout = linesout, lineoffset = lineoffset, final=True)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 1068, in downscale
dsout, dsaudio = super(FieldPAL, self).downscale(lineoffset = 3, audio = final, *args, **kwargs)
TypeError: downscale() got multiple values for keyword argument 'lineoffset'

At the moment ld-dropout-detect is included as a shim for dropout detection. ld-decode should perform the dropout detection instead and populate the JSON with the data.

When testing rev3 decoding a 42K frame file, decoding get progressively slower as the decode continues. Falling to over 1 second per field by about frame 40K.

The issue looks like it's related to the way the JSON output generates a temporary file; the file size (of the main JSON output) is around 16Mb by frame 40K. ld-decode seems to write the whole thing as a .tmp and then copy it to the main .tbc.json causing a massive amount of file IO operations.

Decode command:

python3 lddecode.py /media/sdi/Seagate\ Backup\ Plus\ Drive/SFTP/LDV4300D_2\ Captures/Apple\ Visual\ Almanac/Apple\ Visual\ Almanac_CAV_NTSC_side1_2018-11-26_13-12-45.lds /media/sdi/Seagate\ Backup\ Plus\ Drive/AlmanacDecode/almanac_side1 --start 418

Results in:

Namespace(MTF=1.0, MTF_offset=0.0, frame=False, infile='/media/sdi/Seagate Backup Plus Drive/SFTP/LDV4300D_2 Captures/Apple Visual Almanac/Apple Visual Almanac_CAV_NTSC_side1_2018-11-26_13-12-45.lds', length=None, ntsc=False, outfile='/media/sdi/Seagate Backup Plus Drive/AlmanacDecode/almanac_side1', pal=False, start=418)
Traceback (most recent call last):
File "lddecode.py", line 68, in
for i in range(0, req_frames * 2):
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'

(Note: Similar result if you do not specify --start)

... so that a single-line error doesn't make a whole line go dark or light.

Steps to recreate:

python3 lddecode.py /SFTP/LDV4300D_2\ Captures/AIV/Domesday_DiscSet2/Domesday\ Community\ North_CAV_PAL_side1_Disc\ set\ 2_2018-10-02_15-11-01.lds ~/Capture/output_dd_cn 600 500

Command produces tbc and pcm files. PCM file created is attached; sound contains both original signal and a constant buzzing.

output_dd_cn_audio.zip

The following decode command:

python3 lddecode.py SFTP/Other/DVL909E_AIV_NORTH_POLE_CAV_FULL.lds ~/lddecode_out/NPE_DO_test2 --pal --start 270 --length 20000

Fails with the following error:

starting at 9322153531
status code 9150521
True None
624 312 313
frame 5555
1919
starting at 9322955406
CAV 5556
CAV 5556
False 5556
starting at 9323753553
True None
624 312 313
Traceback (most recent call last):
File "lddecode.py", line 53, in
combined, audio, nextsample, fields = framer_ntsc.readframe(fd, nextsample, f == 0)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 1156, in readframe
self.vbi = self.mergevbi(fields)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 1090, in mergevbi
vbi_merged['framenr'] = vbi_merged['minutes'] * 60 * fps
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'

Running against commit: 3af20e3 branch 'master' of https://github.com/happycube/ld-decode

Steps to reproduce:

sdi@sehodomedupdev01:~/github/ld-decode$ ./comb-ntsc
1
Segmentation fault (core dumped)

Currently the dropout corrector only functions with the video data. This should be expanded to also perform (optional) correction of the .pcm audio files.

Encode command line:

python3 lddecode.py /media/sdi/Seagate\ Backup\ Plus\ Drive/SFTP/LDV4300D_2\ Captures/AIV/Domesday_DiscSet2/Domesday\ National_CAV_PAL_side1_Disc\ set\ 2_2018-10-02_18-14-36.lds ~/lddecode_out/DD_National_testcards_rev3 --pal --start 1856 --length 100 --field

Debug output:

False None
lc 17 0x8ba026
lc 18 0xf01595
lc 19 0xf01595
True 1595
lc 18 0x8ba026
False None
lc 17 0x8ba026
lc 18 0xf01596
lc 19 0xf01596
True 1596

Why 17, 18, 19? (should be 16,17,18 according to spec) Testing with ld-process-vbi shows the field lines are in the correct place.

Make debug one line and readable. For example:
"Processing Field 3014: (VBI: 0x8ba026, 0xf01596, 0xf01596) - Frame #1596 - Even field"

JSON output file should be DD_National_testcards_rev3.tbc.json (produced file DD_National_testcards_rev3.json)
This is important since there may be more JSON files for other extensions (like post-comb-filter files)

Timing in the videoParameters JSON object needed to be changed to allow for the extra 4.7us across the sync-tip:

"videoParameters": {
"activeVideoEnd": 1108,
"activeVideoStart": 186,
"black16bIre": 16128,
"blackLevelEnd": 177,
"blackLevelStart": 148,
"colourBurstEnd": 139,
"colourBurstStart": 99,
"fieldHeight": 313,
"fieldWidth": 1135,
"fsc": 4433619,
"isFieldOrderEvenOdd": true,
"isFieldOrderValid": true,
"isSourcePal": true,
"numberOfSequentialFields": 200,
"sampleRate": 17734476,
"samplesPerUs": 17.734375,
"white16bIre": 54016
}

RGB output via the PAL comb filter was good. Colour saturation looked correct (not blown out by the MTF). Still some sample clipping in the colour bar tests across the saturated colours.

Probably a small bit of 1D fallback at top/bottom.

https://diff.pics/US7Tl7teXb-v/1

When looking at the VBI lines (there should be a maximum of 6) the field ordering seems to change without reason between PAL/NTSC and CAV/CLV.

I'm not sure what's really going on, but it doesn't seem to be possible to work out the correct lines to look for VBI data - it's possibly an off-by-one error somewhere. Some seem to end up with the VBI on lines 30-35 and others 29-34.

I'd suggest decoding 4 test samples - PAL CLV, PAL CAV, NTSC CLV and NTSC CAV and ensuring that the 6 possible VBI lines end up in the correct place in the interlaced field output. At the very least, PAL CLV and PAL CAV don't seem to line up correctly. I'll add more specifics once I have them.

Implement the JSON metadata output according to the ld-decode wiki.

When using PAL you have to use --pal (as NTSC is the default), but if you do specify --ntsc it's not recognised. It would be good to harmonize the options.

Add a crash reporter to lddecode.py that outputs the typical information required for bug-fixing such as:

The current file name
The current frame number
Which part of the code crashed
Any relevant debug
The Python crash output text

The text should make it easy for testers to report errors (and there should be some text like: "Ensure you include the following information when raising issue reports")

ld-decode should output fields in the order in which they are decoded by default (rather than interlaced frames). The JSON metadata (when added) should indicate the field order of the output file (which is not necessarily the correct field order of the actual video - which isn't known by ld-decode).

Interlaced output (the current format) should be made optional until the down-stream tools (like comb-ntsc) are updated. Then interlaced output can be removed as a depreciated feature.

In order to judge the quality of RF captures (in terms of disc and capture-player quality) it would be good to have a 'bogomips' style metric based on a number of technical factors which provides a single 0.00 to 9.99 style grading of a capture sample. Once many RF images are available (especially of the same disc) this will become a valuable first 'sort' to quickly find the best source RF captures.

I propose a scale of 0 to 10 happycubes as the measurement unit :)

The timing of the NTSC output frame from the TBC doesn't seem to be correct. The frame is supposed to start (according to ld-decode rather than the video standard) at the end of the sync-tip:

• NTSC approximate timings:
• Horizontal blanking 10.90 us (consists of):
  -- front-porch 1.50 us
  -- sub-carrier burst 5.30 us (consists of):
  --- sync-tip 4.70 us
  --- breezeway 0.60 us
  -- colour-burst 2.50 us
  -- back-porch 1.60 us
• Active video 52.60 us

This should put the start of the active video line at 0.6 + 2.5 + 1.6uS from the beginning of the frame, but it's actually 0.6 + 2.5 + 1.6 + 0.4uS - and I have no idea where the extra .4uS is coming from.

Note: This isn't a problem for PAL frames where the timing appears correct.

After processing 42,728 frames of NTSC CAV RF capture the lddecode.py command crashed with the following output:

1601
starting at 70935161684
status code 9150521
True None
starting at 70935827859
status code 9150521
False None
frame 42727
1603
starting at 70936496358
status code 9150521
True None
starting at 70937162533
status code 9150521
False None
frame 42728
1601
starting at 70937831028
status code 9150521
Traceback (most recent call last):
File "lddecode.py", line 39, in
combined, audio, nextsample = framer_ntsc.readframe(fd, nextsample, f == 0)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 1027, in readframe
f, sample = self.readfield(infile, sample)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 992, in readfield
f = self.FieldClass(self.rf, rawdecode, 0, audio_offset = self.audio_offset)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 958, in init
self.linelocs3, self.burstlevel = self.refine_linelocs_burst(self.linelocs2)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 845, in refine_linelocs_burst
scaledburst, audio = self.downscale(outwidth=self.outlinelen, channel='demod_burst')
File "/home/sdi/github/ld-decode/lddecode_core.py", line 921, in downscale
dsout, dsaudio = super(FieldNTSC, self).downscale(audio = final, *args, **kwargs)
File "/home/sdi/github/ld-decode/lddecode_core.py", line 615, in downscale
scaled = scale(self.data[0][channel], lineinfo[l], lineinfo[l + 1], outwidth)
IndexError: list index out of range

The command line was as follows:

python3 lddecode.py ~/Capture/War\ of\ the\ worlds_CAV_NTSC_side1_2018-10-03_06-24-34.lds ~/Capture/wowoutputntsc 0 60000

This could be related to the end frame specified as 60,000 (which is more than the frames present in the capture file), however the last frame of the capture should be 43,132 according to the original disc.

Test was performed against commit: d69c3b1

The VBI data is in the correct place for even PAL fields, but off by one for odd fields (line 16 data appears in line 17). Here is some output from ld-process-vbi showing the issue (this is from the Roger Rabbit Bonus CAV disc, but the same issue is found with Domesday National):

Debug: [../ld-process-vbi/vbidecoder.cpp:65] VbiDecoder::process(): Getting metadata for field 39 (Odd)
Debug: [../ld-process-vbi/vbidecoder.cpp:71] VbiDecoder::process(): Getting field-lines for field 39
Debug: [../ld-process-vbi/vbidecoder.cpp:780] VbiDecoder::manchesterDecoder(): No VBI data found in the field line
Info: [../ld-process-vbi/vbidecoder.cpp:77] Processing field 39 16 = "0" 17 = "8ba027" 18 = "881ddd"
Debug: [../ld-process-vbi/vbidecoder.cpp:266] VbiDecoder::translateVbi(): VBI Chapter number is 1
Debug: [../ld-process-vbi/vbidecoder.cpp:306] VbiDecoder::translateVbi(): VBI Disc type is CAV
Debug: [../ld-process-vbi/vbidecoder.cpp:87] VbiDecoder::process(): Updating metadata for field 39
Debug: [../ld-decode-shared/sourcevideo.cpp:163] SourceVideo::seekToFieldNumber(): Called with fieldNumber = 40
Debug: [../ld-decode-shared/sourcefield.cpp:29] SourceField::SourceField(): Object created
Debug: [../ld-decode-shared/sourcevideo.cpp:188] SourceVideo::readRawFieldData(): Called - field length is 355255 words
Debug: [../ld-decode-shared/sourcefield.cpp:37] SourceField::setGreyScaleData(): Called
Debug: [../ld-decode-shared/sourcevideo.cpp:154] SourceVideo::getVideoField(): Completed
Debug: [../ld-process-vbi/vbidecoder.cpp:64] VbiDecoder::process(): Getting metadata for field 40 (Even)
Debug: [../ld-process-vbi/vbidecoder.cpp:71] VbiDecoder::process(): Getting field-lines for field 40
Info: [../ld-process-vbi/vbidecoder.cpp:77] Processing field 40 16 = "8ba027" 17 = "f11508" 18 = "f11508"
Debug: [../ld-process-vbi/vbidecoder.cpp:234] VbiDecoder::translateVbi(): VBI picture number is 11508
Debug: [../ld-process-vbi/vbidecoder.cpp:306] VbiDecoder::translateVbi(): VBI Disc type is CAV
Debug: [../ld-process-vbi/vbidecoder.cpp:326] VbiDecoder::translateVbi(): VBI CX sound is off
Debug: [../ld-process-vbi/vbidecoder.cpp:342] VbiDecoder::translateVbi(): VBI Laserdisc is 12 inch
Debug: [../ld-process-vbi/vbidecoder.cpp:351] VbiDecoder::translateVbi(): VBI Laserdisc side 1
Debug: [../ld-process-vbi/vbidecoder.cpp:360] VbiDecoder::translateVbi(): VBI Disc does not contain teletext
Debug: [../ld-process-vbi/vbidecoder.cpp:369] VbiDecoder::translateVbi(): VBI Video data is analogue
Debug: [../ld-process-vbi/vbidecoder.cpp:380] VbiDecoder::translateVbi(): VBI Programme status code - audio status is 2
Debug: [../ld-process-vbi/vbidecoder.cpp:403] VbiDecoder::translateVbi(): VBI audio status 2 - isProgrammeDump = false - isFmFmMultiplex = false - soundMode = futureUse
Debug: [../ld-process-vbi/vbidecoder.cpp:510] VbiDecoder::translateVbi(): VBI (Am2) CX sound is off
Debug: [../ld-process-vbi/vbidecoder.cpp:526] VbiDecoder::translateVbi(): VBI (Am2) Laserdisc is 12 inch
Debug: [../ld-process-vbi/vbidecoder.cpp:535] VbiDecoder::translateVbi(): VBI (Am2) Laserdisc side 1
Debug: [../ld-process-vbi/vbidecoder.cpp:544] VbiDecoder::translateVbi(): VBI (Am2) Disc does not contain teletext
Debug: [../ld-process-vbi/vbidecoder.cpp:553] VbiDecoder::translateVbi(): VBI (Am2) Copy prohibited
Debug: [../ld-process-vbi/vbidecoder.cpp:564] VbiDecoder::translateVbi(): VBI (Am2) Programme status code - audio status is 2
Debug: [../ld-process-vbi/vbidecoder.cpp:584] VbiDecoder::translateVbi(): VBI (Am2) audio status 2 - isVideoSignalStandard = false - soundMode = futureUse
Debug: [../ld-process-vbi/vbidecoder.cpp:87] VbiDecoder::process(): Updating metadata for field 40
Debug: [../ld-process-vbi/vbidecoder.cpp:100] VbiDecoder::process(): Valid CAV picture number found in field 2
Info: [../ld-process-vbi/vbidecoder.cpp:135] Field order is Even then Odd

As a method to improve captures beyond what's possible from a single image from a single disc and player, it is theoretically possible to combine many RF captures of the same and different discs (taken from many different players) into a single source image - improving the 'information' about the signal and removing random noise (especially drop-outs) from the captures.

Some form of multiple capture processing front-end would provide major improvements to the possible outcome of a decode.

As a future enhancement, it would be great if the decoder could automatically work out the input video standard.

It would be nice to create a test-bench for the ld-decode process with a known set of input signals for each stage. As development ramps up it will be important to be able to rapid test new code for signal processing quality as well as regression testing with something more exact than a real LaserDisc sample (possibly software-generated test images).

Being able to TBC from and to chapters would be helpful

Perhaps:
--from-chapter, -f
--to-chapter, -t

So -f 3 -t 3 would process all of chapter 3. -f 1 -t 5 would do chapters 1-5.

Additionally, being able to seek to a specific side might be useful, in case one captures both sides of a disc in a single capture.

Here is some feedback from the work on the PAL comb filter (copied from an email message):

The captures are too "hot", and the scaling is clipping the chroma peaks in the composite signal.

Attached image shows the "oscilloscope" trace of a line in the colourbars near the top of your TestCard F capture (From Domesday CommN). The height of the white rectangle represents the range 0-255 in 8-bit code. You can clearly see the top of the chroma is clipped.

(Richard Russell said somewhere on one of his testcard pages that Test Card F has "95%" colour bars)
The clipping is worse on the colour-bar images later in that sequence with the red bottom-half of the screen, that are probably 100% colour bars.

For background, see also the images about 2/3rds of the way down this page: https://www.radios-tv.co.uk/Pembers/World-TV-Standards/index.html
and figure 2 on this page: https://www.embedded.com/print/4009973

More specifically, see https://tech.ebu.ch/docs/tech/tech3280.pdf for advice/standards on levels for digitised composite video (there may also be something in Rec.470 or Rec.601 but I haven't looked recently)

For digitised composite (PAL), in 8-bit:

• sync-tip should be at code 01h
• blanking level should be at code 40h (64 decimal)
• peak-white should be at code D3h (211 decimal)

This will give sufficient headroom for the chroma on, for example, the yellow bar of the chroma bar, to go above peak-white, as it needs to.

In your captures of testcard F, for example, blanking level is at about 40 (decimal) and peak white at around 240 (decimal).

I can see that the chroma on the testcard F is clipping - which will reduce the decoded saturation and luminance, of the yellow and, because the chroma is clipped so not sinusoidal, it'll tend to leave 2nd and 3rd harmonic chroma pattern remnants in the image after decoding.

(This is why I'm having to set my video-gain and colour-saturation parameters to 75% rather than 100%, to get acceptable results.)

It'd be good to get the parameters tweaked in the RF demodulation part of the ld-decode software to remedy this (As you're doing 16-bit codes, you won't lose anything in granularity)

It's not the end of the world, but the present result is definitely sub-optimal.

(The recommendations for digitised NTSC are probably similar, though not exactly the same)

When producing a TBC file for a PAL source the JSON indicates that the TBC contents are

Odd Field - frame 1
Even Field - frame 1
Odd Field - frame 2 (etc)

but the actual output is (determined by examining the output in ld-analyse):

Even field - frame 1
Odd field - frame 2
Even field - frame 2

This basically means that ld-analyse cannot get the frame output correct at the moment.

So, the JSON does not match the actual TBC contents. (Note: this does not effect NTSC which looks correct). Here's the JSON output from a PAL decode of DD CommS:

{
"pcmAudioParameters": {
"bits": 16,
"isLittleEndian": true,
"isSigned": true,
"sampleRate": 48000
},
"videoParameters": {
"numberOfSequentialFields": 60,
"isSourcePal": true,
"isFieldOrderEvenOdd": false,
"isFieldOrderValid": true,
"fsc": 4433618,
"fieldWidth": 1135,
"sampleRate": 17734472,
"samplesPerUs": 17.734472,
"black16bIre": 16384.0,
"white16bIre": 54016.0,
"fieldHeight": 313,
"colourBurstStart": 99.0,
"colourBurstEnd": 139.0,
"blackLevelStart": 145.0,
"blackLevelEnd": 177.0,
"activeVideoStart": 186.0,
"activeVideoEnd": 1108.0
},
"fields": [
{
"isEven": false,
"syncConf": 75,
"seqNo": 1,
"medianBurstIRE": 5.1484686969058355
},
{
"isEven": true,
"syncConf": 75,
"seqNo": 2,
"medianBurstIRE": 8.758277435395023
},

ld-decode c++ files do not cleanly compile:

sdi@sehodomedupdev01:~/github/ld-decode$ make all
clang++ -std=c++11 -Wall -g -O2 -fno-omit-frame-pointer -march=native -o cx cx-expander.cxx
cx-expander.cxx:9:14: warning: unused variable 'freq' [-Wunused-const-variable]
const double freq = 48000.0;
^
1 warning generated.
clang++ -lfann -std=c++11 -Wall -g -O2 -fno-omit-frame-pointer -march=native -lopencv_core -lopencv_highgui -lopencv_imgproc -lopencv_video -o comb-ntsc comb-ntsc.cxx
comb-ntsc.cxx:55:14: warning: unused variable 'dots_usec' [-Wunused-const-variable]
const double dots_usec = dotclk / 1000000.0;
^
1 warning generated.
cp comb-ntsc comb
gcc -std=c99 -O2 -o ddpack ddpack.c
gcc -std=c99 -O2 -o ddunpack ddunpack.c

When decoding a .lds file, if you decode frames 1-1000 and then 1001-2000 (for example) there seems to be a gap of about 1.5 frames in the resulting .pcm files when you join them in post processing. In my testing it happened for the first couple of decodes, but the issue wasn't persistent for all decodes.

I'll add more specific recreation instructions if I see the issue again.

Currently the early frames of PAL CLV discs have VITS results that show the signal levels to be out of spec (most likely this is due to the lack of MTF compensation). Adding in some form of MTF compensation would be a good enhancement.

There is also shadowing occurring in early PAL CAV frames that is likely caused by the same issue.

Add a command line switch to make selection of PAL and NTSC video formats simple.

#46 reminded me the TBC has no idea what to do with (player-level) seeking yet. This may not get fixed any time soon, however - just leaving it here to say it's a known issue.

ld-decode.py output (when successfully decoding) should be a lot clearer. One output line per frame with a clear tabulated report on the decode status would be nice. Output like "True None" should state what's true and what it's having none of :)

In a decode of the Almanac disc (side 1) the field order becomes reversed at field 44321, here is a snippet of the JSON output (complete output file attached):

    {
        "isEven": true,
        "syncConf": 75,
        "seqNo": 44319,
        "medianBurstIRE": 14.675160294117648,
        "fieldPhaseID": 3
    },
    {
        "isEven": false,
        "syncConf": 75,
        "seqNo": 44320,
        "medianBurstIRE": 14.630581617647058,
        "fieldPhaseID": 2
    },
    {
        "isEven": false,
        "syncConf": 75,
        "seqNo": 44321,
        "medianBurstIRE": 14.643814705882352,
        "fieldPhaseID": 4
    },
    {
        "isEven": true,
        "syncConf": 75,
        "seqNo": 44322,
        "medianBurstIRE": 14.673281617647058,
        "fieldPhaseID": 3
    },
    {
        "isEven": false,
        "syncConf": 75,
        "seqNo": 44323,
        "medianBurstIRE": 14.676668382352942,
        "fieldPhaseID": 2
    },
    {
        "isEven": true,
        "syncConf": 75,
        "seqNo": 44324,
        "medianBurstIRE": 14.656036397058823,
        "fieldPhaseID": 1
    },

The decode command was as follows:

python3 lddecode.py /media/sdi/Seagate\ Backup\ Plus\ Drive/SFTP/LDV4300D_2\ Captures/Apple\ Visual\ Almanac/Apple\ Visual\ Almanac_CAV_NTSC_side1_2018-11-26_13-12-45.lds /media/sdi/Seagate\ Backup\ Plus\ Drive/AlmanacDecode/almanac_side1_test --length 50000 --start 418

almanac_side1 JSON.zip