ld-analyse improvements & fixes list

[harrypm]

ld-analyse is the primary GUI tool of the decode projects post processing pipeline.

There is a limited amount of features left before it is entirely replacing its analogue & digital waveform monitor/scope physical counterparts.

Half of these features were already developed and tested over a year ago by Jitterbug and me but never PR'ed into upstream.

I am tinkering with improvements on this branch.

Key Features:

Vectorscope improvements

• Vectorscope 1:1 limited scaling mode.
• Vectorscope Zoom scaling mode
• Vectorscope Area & Line Selection Mode

• Load Metadata only, i.g TBCs deleted and the retained files are preserved for metadata, these should be viewable so people can access the graphics data without the need of an additional tool of which non are implemented.

• CTRL+C to copy current display readout. (this is working on improvements branch)

• View mode export, exports a full set of PNG images in all the view mode configs for current fields/frame.

• RGB parade Waveform

• Timecounter, simple time counter of current frame position relative to format timing i.g 25/29.97fps to HH:MM:SS:FF (allowing users to skip the napkin math of figuring out current time in loaded files)

• Full-Frame 4fsc readout with luma and chroma-decoding replacing cutout, this can be done with current-code (tested with GPT 5.1 tweaking)

Full Chroma & Luma decoded raster output (already proven implementable with testing).

Workflow Improvements

• Chroma-decoder settings forward, as these changes regardless of input TBC type are visually represented accurately now, adjustments should be easily forwarded to tbc-video-export / ld-chroma-decoder for export.

(This can open a copy values button or save to JSON/SQL for carry though defaults for the chroma-decoder/tbc-video-export to handle or have FFV1/ProResHQ/V210/Proxy direct modes using the pre-dedfined profiles)

• Red (or RGB adjustable) boundary box around the active area for a more clear active the video parameter adjustment. (will be required when cut-out is replaced by full-frame)

• Sliders for active video area adjustment instead of tiny up/down check boxes. (this would be much more fluid and or enable the border box to be a resizable window within the main GUI window to make this even more faster and easy to use)

Tools Tab

• JSON/DB fixer, when bSNR values are broken and it breaks the graph GUI (tested and working on improvements branch)

• JSON to SQL DB Conversion, expansion of the "Load JSON only" feature to also allow for quick conversion by calling the tool, and refreshing with the new format.

• Scan VBI (run ld-process-vbi)

• Scan VITS (run ld-process-vits)

These functions just pipe the current loaded files to the tools and then reloads the files upon completion saving the user from having to open an CLI window for a simple in and out operation.

Quality of life upgrades

• Scanline scope, signal voltage scale.

• Playback mode (literally just an forward frame play mode, 25fps is fine, 29.97fps had rounding issues with QT, this was overall working fine in Jitterbugs build)

• Sliders for black/white levels alongside the decimal value (already test implemented in Jitterbugs build, way more fluid & intuitive then using scan-line oscilloscope)

• Allow for dead-space cut off or start/end duration setting in metadata, or pass to tbc-cut, as exact frame/field targeting can be easily passed via timeline slider.

• Docs linkage under help, and or highlight/tool-tip menu help descriptions.

• Position & Hex of pointer location.

[simoninns]

"ld-analyse is the primary GUI tool of the decode projects post processing pipeline" - I disagree with this statement and intent. ld-analyse was created for LaserDisc analysis as part of ld-decode. It is true that a lot of things have been bolted on (causing questionable flow and performance for LD users) - but the "one ring to rule them all" approach usually results in one big tool that's not suitable for any individual work-flow instead of suitable for all.

Adding features/stuff to ld-analyse is certainly a tempting path, but assuming that it only needs the 'limited amount' of additional features you envision to be "complete" is folly from a design perspective. I'm pretty sure that others will dream up additional 'must haves' as more and more formats fork ld-decode. For example, dropout management is a key missing LD "feature" for me and doesn't feature in your list.

Instead I would propose splitting ld-analyse in to multiple tools with a common library for things like the display functions. One specialised for viewing decoder output and metadata, one for dropout management and another for chroma-decoder configuration. An alternative could be a single front-end with plugins to extend. Anything other than a big complex app which will be difficult to expand and maintain (which ld-analyse has already become).

This issue conflates these two things - you want features and that's fine (and I'm not even judging if those features are needed or not) - but you also dictate the solution in terms of architecture is to (continue to) stick them all in ld-analyse - which is not necessarily the right approach.

As a final unrelated note to the above - the JSON/SQLite change over is temporary and there is no need to complicate tools because of a shift in the back-end architecture. Once the change over is complete ld-decode will generate SQLite by default. If your workflow is to keep TBC and JSON for a long time - a) your workflow is poor and b) you know what you are doing and can use ld-json-converter.